08:05:03 <d0ugal> #startmeeting mistral
08:05:04 <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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:05:07 <openstack> The meeting name has been set to 'mistral'
08:05:15 <d0ugal> Happy Friday everyone! It is office hour time.
08:05:25 <d0ugal> https://etherpad.openstack.org/p/mistral-office-hours
08:05:37 <d0ugal> PING rakhmerov, apetrich, bobh, mcdoker181818
08:05:53 <apetrich> o/
08:05:56 <apetrich> morning
08:06:33 <d0ugal> No untriaged bugs again, good job!
08:08:51 <hardikjasani> Hey
08:09:03 <d0ugal> Hey hardikjasani
08:09:16 <hardikjasani> What do guys think about https://blueprints.launchpad.net/mistral/+spec/mistral-namespace-for-actions-workbooks ?
08:09:56 * d0ugal reads
08:11:05 <d0ugal> hardikjasani: Makes sense. I'm not sure how it would work for actions? (unless you mean adhoc only?)
08:11:26 <hardikjasani> Yes, it is for ad-hoc actions.
08:11:31 <hardikjasani> I will clarify
08:11:42 <d0ugal> Thanks
08:12:09 <d0ugal> I have never really found a use for ad-hoc actions :)
08:13:59 <rakhmerov> d0ugal: here
08:14:20 <d0ugal> Hey
08:14:56 <rakhmerov> d0ugal: we just talked to hardikjasani recently I told him that blueprints need to be approved for a cycle/milestone officially
08:15:38 <d0ugal> Right
08:15:40 <rakhmerov> otherwise we can create an implementation and then find that core members are against the idea of the change
08:16:00 <d0ugal> hardikjasani: is this something you hope to do for Rocky-3?
08:16:25 <hardikjasani> What is the date for Rocky-3?
08:16:29 <d0ugal> Which is around the end of July
08:16:38 <d0ugal> Jul 23 - Jul 27
08:16:51 <hardikjasani> Yes, I have been working on it already.
08:16:57 <d0ugal> cool
08:17:12 <d0ugal> Then I am okay with is being part of that milestone - unless anyone has objections.
08:17:57 <rakhmerov> d0ugal: +1
08:32:29 <openstackgerrit> Dougal Matthews proposed openstack/mistral master: [WIP] Experimental work adding a Zaqar event publisher  https://review.openstack.org/547666
08:32:42 <d0ugal> rakhmerov: if you have a moment, I have a question about how to finish that patch ^
08:33:18 <d0ugal> or the question can be for anyone really :-D
08:33:20 <rakhmerov> yes
08:33:23 <rakhmerov> ok
08:33:41 <d0ugal> I think I almost have it working, but I can't figure out how to finish this bit
08:33:43 <d0ugal> https://review.openstack.org/#/c/547666/5/mistral/engine/workflows.py
08:33:45 <d0ugal> See the TODO
08:34:09 <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:11 <d0ugal> but not there, yet
08:35:09 <d0ugal> I have to admit being a bit confused by the mistral context at times and when it is available.
08:35:27 <d0ugal> and I also feel like there are multiple different contextes, so I maybe have the wrong thing in some places.
08:39:26 <rakhmerov> d0ugal: yeah.. so
08:39:33 <d0ugal> :)
08:39:38 <rakhmerov> :)
08:40:04 <rakhmerov> in mistral-lib we recently added Context splitted in turn into "security" and "context"
08:40:48 <rakhmerov> ad the notification mechanism is missing something similar
08:40:56 <d0ugal> Right
08:41:06 <rakhmerov> we were aware of that (Winson's debt actually) and Winson was going to add it
08:41:22 <d0ugal> yeah, I gave up and thought I would try to add it myself
08:41:55 <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:42:00 <rakhmerov> yep
08:42:29 <rakhmerov> so 1) we definitely need to add it
08:42:43 <rakhmerov> but 2) not sure if we need to make it the same thing as in mistral-lib
08:42:51 <d0ugal> Right
08:42:53 <rakhmerov> because that context is for actions
08:43:03 <rakhmerov> with all the consequences..
08:43:13 <d0ugal> Yeah, that feels quite different to me
08:43:25 <rakhmerov> action authors won't have to have a dependency on mistral repo
08:43:40 <rakhmerov> d0ugal: yeah, to me too
08:44:15 <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:37 <d0ugal> but initially I'd like to just figure out the plumbing to make it work
08:44:46 <rakhmerov> the commonality is that publishers are also a pluggable thing
08:45:01 <rakhmerov> yeah... thinking..
08:45:21 <d0ugal> IMO the publisher work is mostly uselss at the moment :(
08:45:44 <rakhmerov> I'm just thinking whether a publisher author should know about mistral-lib (or mistral)
08:45:55 <rakhmerov> d0ugal: yes, that bit is obviously missing
08:46:10 <d0ugal> rakhmerov: I think ideally a publisher should know about mistral-lib only
08:46:28 <d0ugal> but I think it is too late in rocky to refactor it to use mistral-lib
08:47:06 <rakhmerov> d0ugal: you know, I'm actually not sure..
08:47:26 <rakhmerov> because the base class for publishers is in mistral now
08:47:50 <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:59 <d0ugal> and make a mistral-lib release
08:48:40 <rakhmerov> hm.. yeah
08:49:15 <rakhmerov> but I don't know really.. it sounds a little complicated
08:49:23 <d0ugal> Yup :)
08:49:26 <rakhmerov> maybe we just need to leave it in mistral
08:49:40 <rakhmerov> because we already have lots of pluggable things in "mistral"
08:49:45 <rakhmerov> like Executor
08:49:52 <d0ugal> Indeed
08:49:53 <rakhmerov> expression evaluator
08:49:53 <rakhmerov> etc
08:50:02 <rakhmerov> do we need to move them all to mistral-lib?
08:50:10 <rakhmerov> I don't think so
08:50:23 <rakhmerov> not yet at least )
08:50:36 <d0ugal> I think we should move some of them to mistral-lib
08:50:42 <rakhmerov> may be
08:51:00 <d0ugal> However, I think we should keep the notifier in mistral now, it makes it easier to iterate it and update it
08:51:08 <rakhmerov> but then particular implementations I think should be moved somewhere else, no?
08:51:11 <d0ugal> Then we can maybe move it to mistral-lib is we think it makes sense and it is stable.
08:51:19 <rakhmerov> yes
08:51:21 <rakhmerov> ok, agree
08:51:54 <rakhmerov> but to me it sees legitimate to still use Context from mistral-lib when calling "publish" method
08:51:55 <d0ugal> Then the Zaqar publisher should probably move to mistral-extra :)
08:51:57 <rakhmerov> what do you think?
08:52:02 <rakhmerov> d0ugal: yeah :)
08:52:16 <d0ugal> Sure, I am happy to use the mistral-lib context - it keeps it consistent.
08:52:31 <rakhmerov> yeah, I think some of the "core and stable" implementations can stay in mistral but some can move to extra
08:52:37 <rakhmerov> ok
08:52:39 <d0ugal> However, I have no idea how to get that context at every point we call .publish()
08:53:22 <rakhmerov> well, we need to look at the chain call from the engine to this method
08:53:41 <rakhmerov> as I remember, it goes through something else (Notifier?)
08:53:49 <d0ugal> Yup
08:53:55 <rakhmerov> the "execution" part is available in the engine
08:54:31 <rakhmerov> the security part can be also taken through auth.context()
08:55:29 <rakhmerov> from mistral import context as auth_ctx
08:56:05 <rakhmerov> seems like for "execution" part it'd be nice to have a thread local variable may be
08:56:08 <d0ugal> https://github.com/openstack/mistral/blob/fc7877ec5269a932b1c1d05a1ab17d615af9931b/mistral/context.py#L260
08:56:12 <rakhmerov> similar to the security context
08:56:44 <rakhmerov> yes!
08:57:10 <d0ugal> I forgot I added that method.
08:57:41 <rakhmerov> :)
08:58:05 <rakhmerov> d0ugal: it'd be good to finish this notification thing in R-3
08:58:16 <d0ugal> rakhmerov: Yeah, I really want to.
08:58:17 <rakhmerov> I know people who are interested in it
08:58:25 <rakhmerov> yep
08:58:28 <d0ugal> I want TripleO to use it with Zaqar :)
08:58:37 <rakhmerov> good to know, ok
08:59:03 <d0ugal> and I guess it would be useful for the UI you have also
08:59:23 <rakhmerov> yes, exactly )
08:59:59 <d0ugal> rakhmerov: so you would add a execution context to that file like with the security context?
09:00:17 <d0ugal> It is unfotunate that the security context is just called context in most places.
09:00:27 <d0ugal> The name context is lacking context ;)
09:00:59 <rakhmerov> :)) haha
09:01:01 <rakhmerov> yeah..
09:01:14 <d0ugal> #endmeeting