openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Add info about source execution to a workflow execution description https://review.openstack.org/577348 | 05:24 |
---|---|---|
rakhmerov | apetrich: hi, it was very fast ^ :) | 05:34 |
rakhmerov | thanks! | 05:35 |
apetrich | rakhmerov, I was just starting the day :) | 05:35 |
rakhmerov | good timing then! ) | 05:35 |
apetrich | I'm a bit more productive before the kids wake up | 05:35 |
rakhmerov | haha ) | 05:35 |
rakhmerov | watch the worldcup? ) | 05:35 |
rakhmerov | I didn't sleep a lot today because I watched Arg - Cro | 05:36 |
rakhmerov | it was from 1 till 3 am | 05:36 |
*** AlexeyAbashkin has joined #openstack-mistral | 05:54 | |
*** hardikjasani has joined #openstack-mistral | 05:57 | |
rakhmerov | apetrich: the patch is failing, trying to understand why.. | 05:58 |
*** AlexeyAbashkin has quit IRC | 06:13 | |
apetrich | rakhmerov, commented on the tox error that I got here | 06:20 |
rakhmerov | ok | 06:21 |
rakhmerov | yeah, it was just a different test that failed | 06:21 |
rakhmerov | fixed it | 06:21 |
rakhmerov | not sure why the low-constraint Job failed though | 06:21 |
openstackgerrit | Renat Akhmerov proposed openstack/mistral master: Add info about source execution to a workflow execution description https://review.openstack.org/577348 | 06:22 |
apetrich | rakhmerov, works for me. | 06:30 |
*** AlexeyAbashkin has joined #openstack-mistral | 07:10 | |
*** jistr|off is now known as jistr | 07:34 | |
d0ugal_ | Morning! | 08:03 |
*** d0ugal_ has quit IRC | 08:03 | |
*** d0ugal has joined #openstack-mistral | 08:04 | |
d0ugal | #startmeeting mistral | 08:05 |
openstack | Meeting started Fri Jun 22 08:05:03 2018 UTC and is due to finish in 60 minutes. The chair is d0ugal. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:05 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:05 |
*** openstack changes topic to " (Meeting topic: mistral)" | 08:05 | |
openstack | The meeting name has been set to 'mistral' | 08:05 |
d0ugal | Happy Friday everyone! It is office hour time. | 08:05 |
d0ugal | https://etherpad.openstack.org/p/mistral-office-hours | 08:05 |
d0ugal | PING rakhmerov, apetrich, bobh, mcdoker181818 | 08:05 |
apetrich | o/ | 08:05 |
apetrich | morning | 08:05 |
d0ugal | No untriaged bugs again, good job! | 08:06 |
*** shardy has joined #openstack-mistral | 08:08 | |
hardikjasani | Hey | 08:08 |
d0ugal | Hey hardikjasani | 08:09 |
hardikjasani | What do guys think about https://blueprints.launchpad.net/mistral/+spec/mistral-namespace-for-actions-workbooks ? | 08:09 |
* d0ugal reads | 08:09 | |
d0ugal | hardikjasani: Makes sense. I'm not sure how it would work for actions? (unless you mean adhoc only?) | 08:11 |
hardikjasani | Yes, it is for ad-hoc actions. | 08:11 |
hardikjasani | I will clarify | 08:11 |
d0ugal | Thanks | 08:11 |
d0ugal | I have never really found a use for ad-hoc actions :) | 08:12 |
rakhmerov | d0ugal: here | 08:13 |
d0ugal | Hey | 08:14 |
rakhmerov | d0ugal: we just talked to hardikjasani recently I told him that blueprints need to be approved for a cycle/milestone officially | 08:14 |
d0ugal | Right | 08:15 |
rakhmerov | otherwise we can create an implementation and then find that core members are against the idea of the change | 08:15 |
d0ugal | hardikjasani: is this something you hope to do for Rocky-3? | 08:16 |
hardikjasani | What is the date for Rocky-3? | 08:16 |
d0ugal | Which is around the end of July | 08:16 |
d0ugal | Jul 23 - Jul 27 | 08:16 |
hardikjasani | Yes, I have been working on it already. | 08:16 |
d0ugal | cool | 08:16 |
d0ugal | Then I am okay with is being part of that milestone - unless anyone has objections. | 08:17 |
rakhmerov | d0ugal: +1 | 08:17 |
*** AlexeyAbashkin has quit IRC | 08:29 | |
*** josecastroleon has quit IRC | 08:30 | |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: [WIP] Experimental work adding a Zaqar event publisher https://review.openstack.org/547666 | 08:32 |
d0ugal | rakhmerov: if you have a moment, I have a question about how to finish that patch ^ | 08:32 |
d0ugal | or the question can be for anyone really :-D | 08:33 |
rakhmerov | yes | 08:33 |
rakhmerov | ok | 08:33 |
d0ugal | I think I almost have it working, but I can't figure out how to finish this bit | 08:33 |
d0ugal | https://review.openstack.org/#/c/547666/5/mistral/engine/workflows.py | 08:33 |
d0ugal | See the TODO | 08:33 |
d0ugal | For my Zaqar publisher to work it needs the Mistral context to create a Zaqar client - I think I was able to pass it everywhere else | 08:34 |
d0ugal | but not there, yet | 08:34 |
d0ugal | I have to admit being a bit confused by the mistral context at times and when it is available. | 08:35 |
d0ugal | and I also feel like there are multiple different contextes, so I maybe have the wrong thing in some places. | 08:35 |
rakhmerov | d0ugal: yeah.. so | 08:39 |
d0ugal | :) | 08:39 |
rakhmerov | :) | 08:39 |
rakhmerov | in mistral-lib we recently added Context splitted in turn into "security" and "context" | 08:40 |
rakhmerov | ad the notification mechanism is missing something similar | 08:40 |
d0ugal | Right | 08:40 |
rakhmerov | we were aware of that (Winson's debt actually) and Winson was going to add it | 08:41 |
d0ugal | yeah, I gave up and thought I would try to add it myself | 08:41 |
rakhmerov | he said that it wasn't quite clear for him how exactly this context should have been used so that's why we also wanted to make another publisher implementation and see what we need there | 08:41 |
rakhmerov | yep | 08:42 |
rakhmerov | so 1) we definitely need to add it | 08:42 |
rakhmerov | but 2) not sure if we need to make it the same thing as in mistral-lib | 08:42 |
d0ugal | Right | 08:42 |
rakhmerov | because that context is for actions | 08:42 |
rakhmerov | with all the consequences.. | 08:43 |
d0ugal | Yeah, that feels quite different to me | 08:43 |
rakhmerov | action authors won't have to have a dependency on mistral repo | 08:43 |
rakhmerov | d0ugal: yeah, to me too | 08:43 |
d0ugal | So eventually we should try and do a similar thing for publishers? So that you just need to depend on mistral-lib and write against that? | 08:44 |
d0ugal | but initially I'd like to just figure out the plumbing to make it work | 08:44 |
rakhmerov | the commonality is that publishers are also a pluggable thing | 08:44 |
rakhmerov | yeah... thinking.. | 08:45 |
d0ugal | IMO the publisher work is mostly uselss at the moment :( | 08:45 |
rakhmerov | I'm just thinking whether a publisher author should know about mistral-lib (or mistral) | 08:45 |
rakhmerov | d0ugal: yes, that bit is obviously missing | 08:45 |
d0ugal | rakhmerov: I think ideally a publisher should know about mistral-lib only | 08:46 |
d0ugal | but I think it is too late in rocky to refactor it to use mistral-lib | 08:46 |
rakhmerov | d0ugal: you know, I'm actually not sure.. | 08:47 |
rakhmerov | because the base class for publishers is in mistral now | 08:47 |
rakhmerov | if we want to have a dependency to mistral-lib only we need to move the base class to mistral-lib too | 08:47 |
d0ugal | and make a mistral-lib release | 08:47 |
rakhmerov | hm.. yeah | 08:48 |
rakhmerov | but I don't know really.. it sounds a little complicated | 08:49 |
d0ugal | Yup :) | 08:49 |
rakhmerov | maybe we just need to leave it in mistral | 08:49 |
rakhmerov | because we already have lots of pluggable things in "mistral" | 08:49 |
rakhmerov | like Executor | 08:49 |
d0ugal | Indeed | 08:49 |
rakhmerov | expression evaluator | 08:49 |
rakhmerov | etc | 08:49 |
rakhmerov | do we need to move them all to mistral-lib? | 08:50 |
rakhmerov | I don't think so | 08:50 |
rakhmerov | not yet at least ) | 08:50 |
d0ugal | I think we should move some of them to mistral-lib | 08:50 |
rakhmerov | may be | 08:50 |
d0ugal | However, I think we should keep the notifier in mistral now, it makes it easier to iterate it and update it | 08:51 |
rakhmerov | but then particular implementations I think should be moved somewhere else, no? | 08:51 |
d0ugal | Then we can maybe move it to mistral-lib is we think it makes sense and it is stable. | 08:51 |
rakhmerov | yes | 08:51 |
rakhmerov | ok, agree | 08:51 |
rakhmerov | but to me it sees legitimate to still use Context from mistral-lib when calling "publish" method | 08:51 |
d0ugal | Then the Zaqar publisher should probably move to mistral-extra :) | 08:51 |
rakhmerov | what do you think? | 08:51 |
rakhmerov | d0ugal: yeah :) | 08:52 |
d0ugal | Sure, I am happy to use the mistral-lib context - it keeps it consistent. | 08:52 |
rakhmerov | yeah, I think some of the "core and stable" implementations can stay in mistral but some can move to extra | 08:52 |
rakhmerov | ok | 08:52 |
d0ugal | However, I have no idea how to get that context at every point we call .publish() | 08:52 |
rakhmerov | well, we need to look at the chain call from the engine to this method | 08:53 |
rakhmerov | as I remember, it goes through something else (Notifier?) | 08:53 |
d0ugal | Yup | 08:53 |
rakhmerov | the "execution" part is available in the engine | 08:53 |
rakhmerov | the security part can be also taken through auth.context() | 08:54 |
rakhmerov | from mistral import context as auth_ctx | 08:55 |
rakhmerov | seems like for "execution" part it'd be nice to have a thread local variable may be | 08:56 |
d0ugal | https://github.com/openstack/mistral/blob/fc7877ec5269a932b1c1d05a1ab17d615af9931b/mistral/context.py#L260 | 08:56 |
rakhmerov | similar to the security context | 08:56 |
rakhmerov | yes! | 08:56 |
d0ugal | I forgot I added that method. | 08:57 |
rakhmerov | :) | 08:57 |
rakhmerov | d0ugal: it'd be good to finish this notification thing in R-3 | 08:58 |
d0ugal | rakhmerov: Yeah, I really want to. | 08:58 |
rakhmerov | I know people who are interested in it | 08:58 |
rakhmerov | yep | 08:58 |
d0ugal | I want TripleO to use it with Zaqar :) | 08:58 |
rakhmerov | good to know, ok | 08:58 |
d0ugal | and I guess it would be useful for the UI you have also | 08:59 |
rakhmerov | yes, exactly ) | 08:59 |
d0ugal | rakhmerov: so you would add a execution context to that file like with the security context? | 08:59 |
d0ugal | It is unfotunate that the security context is just called context in most places. | 09:00 |
d0ugal | The name context is lacking context ;) | 09:00 |
rakhmerov | :)) haha | 09:00 |
rakhmerov | yeah.. | 09:01 |
d0ugal | #endmeeting | 09:01 |
*** openstack changes topic to " (Meeting topic: test)" | 09:01 | |
openstack | Meeting ended Fri Jun 22 09:01:14 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:01 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-06-22-08.05.html | 09:01 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-06-22-08.05.txt | 09:01 |
openstack | Log: http://eavesdrop.openstack.org/meetings/mistral/2018/mistral.2018-06-22-08.05.log.html | 09:01 |
rakhmerov | hm.. | 09:01 |
d0ugal | ^ stopping the bot because we are at time, but I am not going anywhere. | 09:01 |
rakhmerov | dunno, may be just explicitly passing the "execution" part of it is OK for now | 09:02 |
therve | d0ugal: One thing that occurred to me for that Zaqar publisher: checking performance would be important | 09:02 |
d0ugal | That does make it a bit easier. | 09:02 |
rakhmerov | not sure how hard it is to maintain a thread local actually copy of it | 09:02 |
d0ugal | therve: Good point. It wouldn't be enabled by default but I'll try and test that. | 09:03 |
rakhmerov | because if we decide to maintain a thread local object we'll have to update it everytime when we go on processing another execution object (e.g. a task or an action) | 09:03 |
therve | d0ugal: We have a somewhat similar mechanism in heat, and I couldn't enable it because of performance | 09:03 |
d0ugal | rakhmerov: good point, we should avoid that. | 09:03 |
rakhmerov | therve: any details on what was the bottleneck/main problem? | 09:04 |
therve | rakhmerov: Well, 1k http requests added | 09:04 |
d0ugal | ooft :) | 09:04 |
therve | That's roughly the number of events when you deploy a tripleo heat stack | 09:04 |
rakhmerov | aha | 09:05 |
rakhmerov | I see | 09:05 |
d0ugal | I think we typically have less events, but maybe we can add a way to configure which events are published | 09:05 |
therve | I guess you may not have as many :) | 09:05 |
*** josecastroleon has joined #openstack-mistral | 09:05 | |
rakhmerov | d0ugal: yes, indeed we need this flexibility. Not sure though if we have it already | 09:05 |
rakhmerov | for example, can we configure (in the config) that we're not interested in events about actions? | 09:06 |
d0ugal | rakhmerov: I don't think we do yet | 09:06 |
rakhmerov | but only about workflows and tasks | 09:06 |
rakhmerov | aah... | 09:06 |
rakhmerov | we spent so much time in Denver to push this through.. | 09:06 |
rakhmerov | Bob was pushing it hard | 09:06 |
rakhmerov | so that we could do that | 09:07 |
d0ugal | I'll open a bug for this | 09:07 |
rakhmerov | ok | 09:07 |
d0ugal | therve: btw, I was thinking about your idea to publish events to a queue named after the workflow | 09:08 |
therve | d0ugal: Well, I mentioned a configurable name, but that works too :) | 09:08 |
d0ugal | therve: I think that could be difficult to use - take the tripleo-ui case, it doesn't know which workflows were started (if it was another user/client) | 09:08 |
d0ugal | therve: oh, right, it should at least be configurable | 09:08 |
d0ugal | I thought you had more in mind - ignore that then. | 09:09 |
d0ugal | I just hadn't gotten to that bit yet. | 09:09 |
therve | d0ugal: Yeah pre-determined names are annoying | 09:09 |
d0ugal | +1 | 09:09 |
therve | I thought about having a workflow parameter, but you talked about subworkflows | 09:10 |
d0ugal | Yeah, it gets tricky. I'll experiment with names once I get it sort of working. | 09:13 |
d0ugal | rakhmerov: btw it looks like we don't have any action events - only workflows and tasks. | 09:13 |
d0ugal | https://github.com/openstack/mistral/blob/master/mistral/notifiers/notification_events.py | 09:14 |
*** shardy has quit IRC | 09:16 | |
rakhmerov | ahh.. | 09:17 |
*** shardy has joined #openstack-mistral | 09:17 | |
*** AlexeyAbashkin has joined #openstack-mistral | 09:36 | |
*** d0ugal has quit IRC | 09:55 | |
*** d0ugal has joined #openstack-mistral | 09:56 | |
openstackgerrit | Merged openstack/mistral master: Amend the spelling error of a word https://review.openstack.org/576045 | 09:57 |
*** hardikjasani has quit IRC | 11:17 | |
*** AlexeyAbashkin has quit IRC | 11:57 | |
*** AlexeyAbashkin has joined #openstack-mistral | 12:11 | |
*** toure|gone is now known as toure | 12:20 | |
*** mmethot has quit IRC | 12:47 | |
*** mmethot has joined #openstack-mistral | 13:17 | |
*** jistr is now known as jistr|mtg | 13:20 | |
*** mfedosin has quit IRC | 13:20 | |
*** jistr|mtg is now known as jistr | 13:37 | |
*** jistr is now known as jistr|mtg | 13:43 | |
openstackgerrit | Stephen Finucane proposed openstack/mistral master: Autogenerate configuration documentation https://review.openstack.org/577157 | 13:52 |
*** josecastroleon has quit IRC | 14:01 | |
*** josecastroleon has joined #openstack-mistral | 14:02 | |
*** jistr|mtg is now known as jistr | 14:09 | |
*** mfedosin has joined #openstack-mistral | 14:45 | |
*** jistr is now known as jistr|afk | 15:30 | |
*** jistr|afk is now known as jistr | 15:32 | |
*** jistr is now known as jistr|off | 15:50 | |
*** josecastroleon has quit IRC | 15:56 | |
*** rbrady is now known as rbrady-afk | 16:21 | |
*** bobh has joined #openstack-mistral | 16:22 | |
*** bobh has quit IRC | 16:28 | |
*** AlexeyAbashkin has quit IRC | 18:44 | |
*** cmurphy is now known as cmurphy_vacation | 19:31 | |
*** mmethot has quit IRC | 19:55 | |
*** mmethot has joined #openstack-mistral | 20:27 | |
*** AlexeyAbashkin has joined #openstack-mistral | 21:02 | |
*** AlexeyAbashkin has quit IRC | 21:11 | |
*** toure is now known as toure|gone | 21:25 | |
*** weshay_PTO has quit IRC | 22:57 | |
*** weshay has joined #openstack-mistral | 22:57 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!