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