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