08:00:50 #startmeeting mistral 08:00:51 Meeting started Fri Apr 13 08:00:50 2018 UTC and is due to finish in 60 minutes. The chair is d0ugal. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:00:54 The meeting name has been set to 'mistral' 08:01:00 It is the Friday office hour! \o/ 08:01:39 I am probably going to try and do some more triage today. I have done quite a bit over the last week. 08:01:41 https://etherpad.openstack.org/p/mistral-office-hours 08:02:01 I added some useful lauchpad links to the etherpad to help with this. 08:02:23 But also happy to discuss any topics that people might have. 08:02:40 hello, I happen to have a question :) 08:02:56 pgaxatte: sure, ask away! 08:03:08 i don't get the openstack action definition create 08:03:35 i haven't seen documentation on this and I don't see what I could create with this call 08:03:53 since a new action would need a python module on the server 08:04:14 pgaxatte: Have you seen ad-hoc actions? 08:04:36 https://docs.openstack.org/mistral/mitaka/dsl/dsl_v2.html#ad-hoc-actions 08:04:47 I have never actually made them with this CLI command 08:05:33 ohhhh ok 08:06:07 it is used to make custom actions that extend available actions 08:06:16 pgaxatte: yes, I believe so 08:06:35 I have only created ad-hoc actions with workbook files, but I believe that is what the CLI is for 08:06:39 rakhmerov: can you confirm? 08:06:41 the reason I stumbled on this is that I need to remove some actions which we won't use / don't want to provide 08:07:00 pgaxatte: I see - which actions do you want to remove? 08:08:15 std.{email,js,javascript,http,ssh...} and the parts of the openstack api that we don't have 08:08:43 pgaxatte: there is no way that I know to remove the std.* actions, but you can remove the openstack actions. 08:09:04 is there a way to make some actions admin only? 08:09:17 pgaxatte: You need to provide the populate command a custom mapping file: https://github.com/openstack/mistral/blob/master/mistral/actions/openstack/mapping.json 08:09:29 pgaxatte: I don't believe so. 08:09:40 d0ugal: thanks I'll check that out 08:10:41 we are trying to see if we can safely provide mistral to our customers but we'd like to avoid people who spam/execute funny stuff through mistral 08:10:54 yeah, makes sense. 08:10:55 hey 08:10:59 give me 1 min 08:11:01 reading... 08:11:04 std.email is easy to disable, I just need to not configure emails :) 08:12:11 d0ugal: I confirm, yes 08:12:18 this CLI command is for uploading ad-hoc actions 08:12:49 because for other actions there's more to do to make them work (server side code, plugin conf in setup.cfg etc.) 08:14:43 rakhmerov: is there a way to restrict the std.* actions? either to remove them or specific users only? 08:15:21 d0ugal: btw, it's a really valid inquiry to be able to remove actions 08:15:31 nope 08:15:48 the only way I could think of is just to delete lines from setup.cfg 08:16:04 so that they don't get registered in DB during installation 08:16:33 d0ugal: seems like it again falls into what we discussed at the PTG about refactoring of actions 08:16:38 action providers etc. 08:16:49 yeah 08:16:54 I want to try and look at that soon. 08:16:58 when we get there we could include this requirement into the list of work items 08:17:03 yeah 08:17:07 it'd be awesome 08:17:18 rakhmerov: I guess that would mean building a custom mistral-common package (on ubuntu) with a modified setup.cfg 08:17:30 d0ugal: I'll get to back to the community work I hope soon too. Once I fix some critical bugs 08:17:36 :) 08:19:56 d0ugal: as far as the issue I described today with memory consumption, it's pretty interesting one. I think we'll have to change the architecture a little bit 08:20:06 it'd be an interesting task 08:20:21 What change do you have in mind? 08:21:06 rakhmerov, sorry for the empty release note template.. LOL I did that on my laptop and forgot to send it to this computer 08:23:15 d0ugal: most likely we shouldn't process all tasks in "on-XXX" at once 08:23:26 apetrich: that's fine ) No worries 08:25:02 rakhmerov: Maybe we could add a concurrency to it? or have it respect the task concurrency? 08:25:31 or do you just think they should be sequential? 08:25:43 d0ugal: yeah, maybe 08:25:52 I'm thinking about it now and doing some more experiments 08:26:05 I think I'll roll out something early next week 08:26:21 d0ugal: well, theoretically yes, we can process that in parallel 08:26:35 to some extent at least 08:26:51 ok, that's just something I wanted to share a little bit 08:27:05 have been busy with it the whole week 08:27:17 d0ugal: so what about bug triaging? ) 08:27:19 Sounds interesting! 08:27:59 rakhmerov: well, we still have 20 NEW bugs: https://bugs.launchpad.net/mistral/+bugs?search=Search&field.status=New&orderby=id&start=0 08:28:14 and 19 UNDECIDED: https://bugs.launchpad.net/mistral/+bugs?search=Search&field.importance=Undecided&orderby=id&start=0 08:28:23 (many of these overlap) 08:28:24 yep 08:28:35 I'm ready to discuss whatever is needed 08:28:36 so I think only 20 in total that need to be triaged 08:28:41 ok 08:28:42 rakhmerov: thanks 08:28:51 I don't know of any that need discussed yet, they just need processed :) 08:29:34 We need to move them to triaged if they seem valid, set a priority and add any relevant tags. 08:29:45 let's do it then? 08:29:52 Sure 08:30:01 rakhmerov: do you want to start at the top of the list? 08:30:09 sure 08:30:15 https://bugs.launchpad.net/mistral/+bugs?search=Search&field.status=New&orderby=-date_last_updated&start=0 08:30:24 That is sorted by date, so should be a consistent view for both of us. 08:30:32 https://bugs.launchpad.net/mistral/+bug/1413535 08:30:32 Launchpad bug 1413535 in Mistral "Method DbTestCase.heavy_init() gets called more than once if we run tests via tox" [Medium,New] - Assigned to Nikolay Makhotkin (nmakhotkin) 08:30:48 there was really a problem with this one 08:30:52 with tox 08:31:00 seems like because of testr 08:31:15 because it may run tests in parallel 08:31:26 Interesting. 08:31:36 so it still looks valid for me but I have no idea how to fix it ) 08:31:39 I don't really understand it. 08:31:42 haha, I don't either. 08:31:50 Okay - I guess we can just mark it as triaged 08:32:07 yes 08:32:36 so, to be precise: not even just "in parallel" but, what's more important, in different processes 08:33:42 https://bugs.launchpad.net/mistral/+bug/1556839 08:33:42 Launchpad bug 1556839 in Mistral "can not generate a snapshot name include date" [Undecided,New] - Assigned to lvdongbing (dbcocle) 08:34:30 In YAQL there is a date function, so I think this is invalid 08:34:48 Maybe there wasn't in 2016 :) 08:35:14 <% "{0}/{1}.yaml".format($.type, now().format("%Y-%m-%d_%H:%M:%S")) %> 08:35:23 yeah.. 08:35:27 ^ we use that in one of our workflows. 08:35:33 I don't think it's a Mistral problem 08:35:38 it's a matter of how to use it 08:36:00 seems just invalid to me 08:36:02 I hope they were not waiting 2 years for that :) 08:36:19 https://bugs.launchpad.net/mistral/+bug/1583210 08:36:19 Launchpad bug 1583210 in Mistral "Mistral Step incorrectly reporting success" [Undecided,New] - Assigned to Hardik Parekh (hardik-parekh047) 08:36:33 Adriano Petrich proposed openstack/mistral master: Only allow for deleting completed executions https://review.openstack.org/560802 08:37:00 I think that bug is a confusion between action executions and tasks. In their case I think the action is successful but the task isn't. 08:37:47 d0ugal: looking.. 08:38:52 yes, you're right 08:39:01 rakhmerov: and I think you said this in the comment :) 08:39:07 yep ) 08:39:44 d0ugal: not even sure whether we need to be solving it somehow 08:39:52 I don't think so 08:39:57 yes 08:40:04 How can we solve it? if the task has an error it has an error and we need to show that :) 08:40:16 well, just a sec.. 08:40:16 Closing it. 08:40:21 oh, okay 08:40:23 waiting 08:40:30 so 08:40:47 I was just trying to understand precisely what the request was ) 08:40:57 Adriano Petrich proposed openstack/python-mistralclient master: WIP force delete executions https://review.openstack.org/561159 08:40:58 and seems like there's no request to change anything 08:41:19 yeah, I think it was just wrong understanding of these mechanisms 08:41:23 let's close it, I agree 08:42:05 ok 08:42:11 https://bugs.launchpad.net/mistral/+bug/1624445 08:42:12 d0ugal: Error: malone bug 1624445 not found 08:42:27 hmm 08:42:34 https://bugs.launchpad.net/mistral/+bug/1624445 08:42:42 Next bug ^ I'm still clsoing this one. 08:42:52 oh, it is private that is why openstack can't fetch it :) 08:43:28 yes 08:43:30 I see it 08:43:53 d0ugal: why closing? 08:44:04 you mean https://bugs.launchpad.net/mistral/+bug/1624445 ? 08:44:04 rakhmerov: Error: malone bug 1624445 not found 08:44:14 rakhmerov: I am still closing the previous one (well, commenting to explain why) 08:44:19 ooh, ok 08:45:06 rakhmerov: I don't think this needs to be private? 08:46:14 hm.. 08:46:19 not sure either 08:46:39 seems like yes, there's a problem but it can't be used to compromise something.. 08:47:01 Agreed. I'll remove the private flag 08:47:30 I think there is enough information here, so I'll mark it as Triaged and Medium. 08:47:42 yes 08:49:45 looking at https://bugs.launchpad.net/mistral/+bug/1640479 08:49:45 Launchpad bug 1640479 in Mistral "401 issue while installing mistral in Openstack" [Undecided,New] 08:50:19 Hmm 08:50:44 There is really not very much information there. 08:51:13 d0ugal: "With Openstack mitaka setup" :) 08:51:19 very very old 08:51:23 lol, yeah 08:51:28 let's close it 08:51:32 I have never even used that Mistral :) 08:51:35 Agreed 08:51:41 I don't think it's relevant 08:52:07 https://bugs.launchpad.net/mistral/+bug/1643840 08:52:07 Launchpad bug 1643840 in Mistral "How to check where are the bugs when the execution status is error" [Undecided,New] 08:53:37 so, on that one: a known thing, yeah, and I already replied that we're working on making this kind of investigation easier 08:54:12 I'd say we don't need to keep this 'bug', it's just another evidence for us that what we started doing in that direction is important for users 08:54:26 Agreed 08:54:38 and revisit our activities on that 08:55:56 https://bugs.launchpad.net/mistral/+bug/1648646 08:55:57 Launchpad bug 1648646 in Mistral "os_actions_endpoint_type not in generated config file" [Undecided,New] 08:56:32 Interesting. 08:56:39 I am sure I have seen the [api] section at least 08:56:42 I should try this... 08:57:01 :) 08:58:01 Andras also complained that some of the options didn't get to a generated config 08:58:08 don't remember though what they were 08:59:22 okay, so we should investigate this. 09:00:01 I remember Andras complaining about it too :) 09:00:11 yeah 09:00:14 Okay, we are at the end of the hour. 09:00:22 d0ugal: btw, it should get into the default group 09:00:23 I might do a little bit more, but I'll stop the bot before I forget. 09:00:28 #endmeeting