16:20:55 #startmeeting Mistral 16:20:55 Meeting started Mon Aug 31 16:20:55 2015 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:20:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:20:58 The meeting name has been set to 'mistral' 16:21:04 hi 16:21:10 hi all 16:21:14 Hi 16:21:18 hi! 16:21:28 hi 16:21:30 hi guys 16:21:53 ok, let's start 16:22:18 Hi 16:22:21 hi 16:22:29 hi 16:22:44 hi Winson 16:22:59 agenda is simple today: https://wiki.openstack.org/wiki/Meetings/MistralAgenda 16:23:11 #topic Review action items 16:23:29 1. rakhmerov: start ML discussion about the best approach for https://blueprints.launchpad.net/mistral/+spec/mistral-execution-origin 16:23:36 it's not actually done again 16:23:50 sorry for that, I'll do it right after the meeting 16:24:00 it's ok 16:24:05 2. akhmerov, xylan_kong: figure out the destiny of Service API blueprints (server and client side) 16:24:05 hi 16:24:11 akuznetsova: hi! 16:24:25 done, i have found it, finally 16:24:45 yep, done 16:24:47 ok 16:25:00 status, quickly.. 16:25:05 #topic Current status (progress, issues, roadblocks, further plans) 16:25:17 I done with bug today (fix + test) https://bugs.launchpad.net/mistral/+bug/1484138 16:25:19 Launchpad bug 1484138 in Mistral "Expiration Policy for executions failed to delete executions " [Undecided,In progress] - Assigned to Guy Paz (guy-paz) 16:25:36 working on fixing mistral resource type 16:25:49 my status: still working on documentation, config guide, quickstart and architecture are done, next - terminology 16:26:20 my status: 1) made it possible to create cycles in direct workflow, the only limitation is that we can't use joins in cycles yet 2) refactored API layer with json type for WSME fields 16:26:23 Still working on fixing the postgresql unit tests. Have 1 patch in but still have other issues. Slow progress as this is not my priority. 16:26:29 I'll update for Liat - she pushed https://review.openstack.org/218839 today 16:26:32 my status: fixed some bugs, discuss how to implement action_execution deletion 16:26:51 Mistral-dashboard: Tasks list - addition of Output column and screen 16:27:03 gpaz: great, I saw your email but didn't have time actually to reply 16:27:19 NikolayM: good job about the doc work! 16:27:25 email not relevant I found how to do that, tahnks :) 16:27:31 LimorStotland: yep, saw your patch. It looks ok to me but someone from Heat voted -1 16:27:32 xylan_kong, thanks :) 16:27:43 gpaz: great, sorry again 16:27:56 rakhmerov, np 16:28:04 thanks NikolayM i am on it :-) 16:28:18 melisha: ok, good 16:28:50 NikolayM: really great work on doc patches! 16:28:57 keep up ) 16:29:51 thanks 16:29:56 m4dcoder: I wish I could participate in your activities too but don't know how to find time for it 16:30:11 all, do we need some help with docs for expiration policy ? 16:30:12 m4dcoder: do you see some serious issues with posgres unit tests? 16:30:24 I might have forgotten some details of it 16:30:35 gpaz: definitely 16:30:59 rakhmerov, lets take it offline, I think I can take that 16:31:08 gpaz: if you could send an initial text we could then polish it and make a good doc out of it 16:31:20 sure 16:31:45 rakhmerov, ok I will, I need some reference how it should look like 16:31:45 rakhmerov: there are some weird timing problems in the unit tests running it on different machines. don't know why. 16:32:14 hm... interesting 16:32:16 rakhmerov: but i have't gotten to the parallel thread issue yet. still trying to get the unit tests to run to completion. 16:32:20 gpaz, initial doc is ready (see documentation patch for main features) 16:32:42 ok, thanks 16:33:07 ok, m4dcoder: we have a syncup with you this week, let's discuss details then. I may be able to help with that (I hope) 16:33:32 rakhmerov: ok 16:33:56 #topic Liberty-3 progress 16:34:49 ok, just wanna take a look at https://launchpad.net/mistral/+milestone/liberty-3 once more 16:34:51 so 16:35:04 most of what's not done yet is documentation stuff 16:35:29 NikolayM: please move to rc1 what you think you won't squeeze into this week, till Friday 16:35:45 but most of it I think will be done 16:36:08 rakhmerov: we don't track client release? 16:36:22 btw, folks, just letting you know: we can do any bugfixing, documentation and UI work in RC releases too 16:36:33 xylan_kong: what do you mean? 16:36:38 rakhemrov, sure 16:36:41 python-mistralclient 16:36:59 yes, but what do you mean by tracking releases? 16:37:06 rakhmerov: Good to know about UI work in RC! 16:37:36 just want to know the status of python-mistralclient 16:37:38 melisha: yes, the only limitation is that we shouldn't be working on any new feature in the service itself 16:37:48 just as https://launchpad.net/mistral/+milestone/liberty-3 16:38:04 xylan_kong: well, for now it's just one BP about execution origin 16:38:07 rakhmerov: Thanks. 16:38:27 so, as a matter of fact, we are tracking it 16:38:44 ok 16:38:48 other than that we might have some bugs in the client 16:39:06 we'll keep fixing them as we go on 16:40:07 melisha: I also wanted to ask Gal about https://blueprints.launchpad.net/mistral/+spec/mistral-dashboard-cron-trigger-screen 16:40:19 but looks like he is not here now 16:40:31 do you happen to know his status on that? 16:40:53 rakhmerov: Gal is still working on executions screen. He did not start with cron-trigger yet 16:40:55 as far as https://blueprints.launchpad.net/mistral/+spec/tasks-screen-improvments, I think we'll move it to RC1 16:41:09 melisha: so is his progress on executions screen? 16:41:31 ..how is his... 16:41:34 rakhmerov: He is progressing. He is now doing the execution update 16:41:40 ok 16:41:50 I'll talk to him tomorrow 16:42:14 just want to estimate if we'll be able to knock these two things down this week 16:42:21 ok, thanks 16:42:24 rakhmerov: OK. Can we start with cron-trigger UI in RC? 16:42:36 yes, we can 16:42:41 it's no problem ) 16:42:47 rakhmerov: Great! Thanks 16:43:04 the reason I'm asking is that I just would like to keep a good pace of development 16:43:05 :) 16:43:23 :-) 16:43:43 #topic Open Discussion 16:44:16 xylan_kong, m4dcoder, NikolayM: let's discuss https://review.openstack.org/#/c/216509/ now 16:44:29 we have Winson's -2 for it 16:44:48 yeah, we have discussed action_exeuction deletion in last meeting, but Winson has different opinions after I submmited my patch. 16:45:13 i'd like we make consensus on that again, so I can continue my work 16:45:20 let's do it 16:45:21 right now 16:45:24 IMO, we should let users to delete their single action executions 16:45:38 NikolayM: sounds reasonable to me 16:45:43 agreed 16:45:43 at least those which don't connected with task executions 16:45:47 m4dcoder: what do you think about this solution? 16:45:52 rakhmerov, from some reason I m not seeing the bug I m working on here : https://launchpad.net/mistral/+milestone/liberty-3 16:46:17 if we limit action execution deletion to the case of single action executions (w/o parent task) 16:46:31 gpaz: which one? 16:46:40 https://bugs.launchpad.net/mistral/+bug/1484138 16:46:41 Launchpad bug 1484138 in Mistral "Expiration Policy for executions failed to delete executions " [Undecided,In progress] - Assigned to Guy Paz (guy-paz) 16:46:46 So I can agree with that. The action executions cannot be tied to any task or WF executions. The action executions has to be in a completed state 16:47:11 gpaz: done 16:47:29 m4dcoder: yes 16:47:33 rakhmerov, thanks 16:47:41 so did we all agree on that? 16:47:53 I like an option where admin has the ability to deny deletion. It's really a security problem. To let someone run a malicious action against your system and have the ability to delete record of it. 16:47:57 xylan_kong: would that work and let us do clean up reasonably? 16:48:04 i mean to run the action thru your system. 16:48:25 m4dcoder: user shoud have ability to delete his own resource, IMO 16:48:36 Except it's not a resource. 16:48:44 m4dcoder: see your point, do we need a new config option then or something? What's the solution you see here? 16:48:53 It's something that happened at a point in time. 16:49:26 ok, m4dcoder, can you describe concisely the best solution you see here? 16:49:37 If we must implement this now, then maybe an config option in the config file. 16:50:14 NikolayM, xylan_kong: what do you think? 16:50:31 i'm afraid i don't agree that 16:50:39 Default of the config option is to not allow deletion. So it's a conscious effort the admin needs to do to allow for this operation. 16:50:50 adding a new config item is a little redundant 16:50:58 xylan_kong: why? 16:51:24 just a use case, it the item is set to False, then as a user, i can delete my 'ad-hoc' action_execution? 16:51:45 s/can/can't 16:52:09 I have faced many cases like this from our customers 16:52:18 ok, let me try to summarize what you can't agree on 16:52:25 so 16:53:03 m4dcoder says that user should not be able to delete even his/her own action executions, even if there ad-hoc (single) 16:53:07 m4dcoder: is that right? 16:53:23 m4dcoder: can you provide your arguments again? 16:53:25 why? 16:54:14 yes. IMHO, executions are something that happened in time. The system should have records of that executions. 16:55:15 ok, I see 16:55:22 If delete operation is allowed, I think it's something that the user and the admins should be aware of and consciously set. 16:55:27 then how could we solve the problem we have? 16:55:41 ok, config option, right? 16:55:50 or some sort of superuser access 16:56:04 config option that admin set. 16:56:12 ok 16:56:21 xylan_kong: your point now 16:56:29 or RBAC policies like you guys mentioned 16:56:43 xylan_kong: where exactly do you disagree? 16:56:53 I just want to make sure users have full access to their own resources. 16:56:57 m4dcoder: yes, I just think it won't happen soon to be honest 16:57:15 i'm ok that we can't delete action_exeucitons that relates to task or workflow 16:57:47 xylan_kong: I am just thinking that maybe m4dcoder is right that it's not a user resource. User itself just asks to something and doesn't know exactly what a system is going to create under the hood 16:57:48 but for ad-hoc action_executions, I can't image the reason why we shoudl keep it 16:57:52 what kind of objects 16:58:09 ok, guys 16:58:28 we have only 2 mins and I want we to find a compromise right now 16:58:57 here's my suggestion: for now we create a config option for enabling action execution deletion 16:59:04 if these are single objects 16:59:18 moving forward it will be managed by RBAC 16:59:34 xylan_kong: is it ok with you? 16:59:44 all right, what i need is a solution that most of people agreed on, and we just do it. 16:59:47 I just don't see how else we can agree 17:00:00 m4dcoder, NikolayM? 17:00:02 deal? 17:00:14 i'm ok with the config option. i don't see any other way forward. 17:00:22 ok 17:00:33 we have to end the meeting 17:00:34 I'm ok with this 17:00:44 thank you all guys for joining 17:00:47 appreciate it 17:00:49 bye! 17:00:51 bye-bye! 17:00:51 thanks. 17:00:52 ok, thanks all 17:00:56 bye 17:00:58 #endmeeting