15:01:33 #startmeeting Mistral 15:01:34 Meeting started Mon Jul 3 15:01:33 2017 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:37 The meeting name has been set to 'mistral' 15:01:42 o/ 15:02:01 hey 15:02:07 waiting.. 15:02:08 hello 15:02:12 hi toure 15:02:20 rakhmerov hello 15:02:20 o/ 15:02:28 hi rbrady 15:02:57 hello rakhmerov. How are you doing? 15:03:07 doing ok ) 15:03:10 still alive 15:03:30 you? 15:03:54 * d0ugal is alive too 15:04:00 :) 15:04:06 it's funny 15:04:19 * toure is mostly alive 15:04:23 but I hope you are feeling better rakhmerov! 15:04:29 i was reading a book yesterday where the author has a joke about the word "job" 15:04:30 +1 15:04:37 about what it means 15:04:43 "just over broke" 15:04:44 rakhmerov: I'm doing okay 15:05:13 just a little better than a bankrupt ) kind of 15:05:35 hah 15:05:41 but I believe we're doing better than this )) 15:05:44 definition 15:05:48 :) 15:05:49 ok, let's start 15:06:00 #topic Current status 15:07:13 my status: spent significant time on reviewing patches, including namespaces spec (please do too), also almost finished Mistral java client in OpenStack4j (will be polishing and testing it) and keep working on HA tasks 15:07:49 specifically, learning OpenStack CI and started working on a new gate 15:08:03 With help from apetrich I was able to remove Mistral from the global requirements, which solved a number of problems 15:08:24 excellent! 15:08:39 my status: slowing working on the port of keystone utils to mistral-lib. I'm not a keystone expert and recent patches/changes have left me reading more code than writing it in the last week 15:08:55 ok 15:09:00 status: workflow error analysis has taken a turn as sub-workflow tracking proves to be difficult, d0ugal pointed out this flaw in my proposal, He and I have been working on a solution. The problem stems from the parent execution not having the ability to track it's children tasks. 15:09:32 yeah, it needs thinking 15:09:41 me: as d0ugal said mistral-lib is going strong. I'm fixing some documentation to reflect that 15:09:44 maybe it's even worth changing the DB model for that 15:09:59 toure: I also left some questions in the patch, take a look 15:10:02 rakhmerov that would help 15:10:14 k, will take a look 15:10:16 also thanks rakhmerov to make the change to mistral-lib serializer so we can remove that from mistral soon 15:10:21 apetrich: documentation where? TripleO? 15:10:28 mistral/docs 15:10:37 https://docs.openstack.org/developer/mistral/developer/creating_custom_action.html 15:10:37 rakhmerov, ^ 15:10:39 ooh, ok 15:11:01 woops 15:11:03 404 15:11:14 I guess it's a temporary problem 15:11:23 ok, good anyway ) 15:11:27 It works for me :) 15:11:31 really? 15:11:33 haha 15:11:48 https://github.com/openstack/mistral/blob/master/doc/source/developer/creating_custom_action.rst 15:12:32 yes, ok 15:13:02 we need to strive to finish all main changes in mistral lib within 2 weeks 15:13:05 it's very important 15:13:15 I'll try to participate too as much as possible 15:13:33 What other changes do we need in mistral-lib? 15:14:00 I see the mistral-extra work (moving actions etc.) as a different task - I am not sure this will happen in time for P 15:14:03 Good question 15:14:20 d0ugal: I think we need to port OpenStack actions, it will prove that everything is ok with mistral-lib 15:14:26 I see the serialization that we can move from mistral into mistral-lib 15:14:37 I think it's not 100% a different task 15:14:47 rakhmerov: Mistral itself uses mistral-lib, that should be proof enough :) 15:14:57 ok, I may be wrong 15:14:57 context will stay in mistral but we could use a contract from mistral-lib 15:14:58 and tripleo does too, which is some external proof. 15:15:15 AFAIK 15:15:17 I haven't really looked into it for a while and I just want to make sure that it's in a good shape 15:15:28 and also documented well 15:15:33 but yes, it would have been nice if mistral-extra used it as that would cover more use cases. 15:15:42 +1 15:16:15 I'm talking about mistral-extra work because it may potentially point to some issues 15:16:18 hopefully not 15:16:36 Right 15:16:37 btw, as with config options used by actions 15:16:49 if we're going to port openstack actions to mistral-extra, does that mean we'll need to port the action generator too 15:16:50 ? 15:17:12 rbrady: yes, I think so. 15:17:23 yes 15:17:40 it's part of the framework related to actions 15:17:48 it shouldn't be in mistral 15:17:48 I had thought about this a bit actually 15:17:55 We have entry_points for invididual actions 15:18:07 but maybe we should have a setup.py entry_point for action generators 15:18:11 there is more to investigate wrt to the action generator imports 15:18:18 then a generator for aws (for example) could be written and registered 15:18:25 I like d0ugal's idea 15:18:38 yeah 15:18:39 sure 15:18:43 but I have not looked into this idea at all :) 15:18:51 There is lots that needs to happen first. 15:19:07 keep in mind that what we've done so far in actions is pretty primitive and not very useable 15:19:35 What do you mean? 15:19:38 there should be better ways of configuring them 15:19:43 aha 15:19:47 I mean your idea is good! ) 15:19:58 Yes, I think mistral-extra will also need a configuration file 15:20:08 don't take what we have now as a good example 15:20:16 Right 15:20:26 d0ugal: sure, yes, but that will be its own config 15:20:28 rakhmerov: configure them? as in configure the client constructors? 15:20:31 of a separate project 15:20:37 in my view 15:21:52 rbrady: no, I mean user experience in general. We have to update that huge mapping if something is out of date, we have to register individual entries in setup.cfg 15:21:53 etc. 15:22:34 I mean when you're working on this transition just try to think how to also improve it 15:22:46 I know there's not much time but anyway 15:22:46 Right 15:22:51 this work will continue anyway 15:22:56 because it would also be better if you didn't need to restart Mistral 15:23:02 people always find that strange :) 15:23:03 yes, ideally 15:23:33 autodiscovery for actions sounds cool 15:23:38 yes 15:23:47 I think we could solve that quite easily by executing actions in their own process - which would also open the door for non-python actions. 15:24:05 true 15:24:23 some time ago we also thought about the idea of an action provider 15:24:37 some abstraction that knows how to deliver actions to the system 15:24:51 its contract is basically: getActions() 15:25:01 and it would return all actions 15:25:12 mmm 15:25:42 once it's integrated we could have implementations of action providers that could fetch actions from whatever comes to our mind 15:26:09 they could generate them dynamically as wrappers around external processes, generate based on DB records, etc. 15:26:51 it's just a general idea but it may be worth thinking of (there's even a BP for that) 15:27:00 yeah, that might be a nice feature for Q 15:27:06 right 15:27:21 do I dare ask about actions as containers? 15:27:22 rakhmerov, do you think have a rabbitmq topic that actions register themselves or a two way communication for getActions to work? 15:27:24 by default, let's say we could have a provider that provides all built-in standard actions 15:27:43 apetrich: yeah, sounds nice 15:27:53 s/actions/actionproviders/ actually 15:27:59 got it, yes 15:28:19 nice 15:28:19 anyway, all these ideas can possibly co-exist 15:28:24 yeah 15:28:46 how to configure them, how to develop the them more efficiently, how to deliver them to the system 15:28:51 lots of ideas ) 15:29:23 let me formally open an open discussion 15:29:27 #topic Open Discussion 15:29:40 one thing to share 15:30:05 you have probably seen the news about migrating docs 15:30:13 kind of a sad news 15:30:15 but 15:30:30 for us it's kind of a good news because we don't need to move docs ) 15:30:36 they are already in our repo 15:31:01 we'll just need to adjust docs according to the spec, basically change folder structure 15:31:22 and it's good that we got volunteers (my colleagues) to do this work 15:31:42 and they also volunteered to improve docs in general, including installation/configuration guides 15:31:49 RPMs, etc. 15:32:41 I think that's pretty much all from me 15:33:12 Great, looking forward to that docs work. 15:33:17 any other topics? 15:33:19 yeah 15:33:37 Nothing from me. 15:33:40 ok 15:33:50 oh, actually 15:33:55 nothing from me either... 15:34:04 [openstack-dev] [tc][all] Move away from meeting channels 15:34:07 ok 15:34:12 d0ugal: yeah? 15:34:29 I seen this discussion on openstack-dev, it seems there might be a move away from these channels 15:34:49 and it also sounds like some projects are moving away from meetings in general 15:35:07 we don't need to change anything, but it is worth reading and we can then discuss what we want to change if anything. 15:35:14 making them ad-hoc? 15:35:30 yes, I read it briefly 15:35:32 I think so 15:35:35 not all the content though 15:35:39 ok, no problem 15:35:50 I'm actually ok with the meetings we have 15:36:08 I still think that they are useful 15:36:26 but we can make them more flexible, for example 15:36:33 not the same day, not the same time 15:36:34 yup 15:36:47 or on demand 15:37:04 if someone wants to discuss something important we can have them 15:37:10 so ok, let's think about it 15:37:26 I don't have any immediate proposals 15:37:31 regarding that 15:37:56 ok 15:38:04 just one more thing from me: as far as my personal contribution, I planned to participate actively in all things like docs and actions but I'll have to be focused on HA because of our internal very strict deadlines 15:38:35 essentially I have to make it work in HA in the next 2 months :) 15:38:41 no choice 15:39:00 but I'll be reviewing and helping anyway 15:39:14 ok, so let's end the meeting earlier then? 15:40:01 d0ugal, rbrady, toure, apetrich? 15:40:06 ack 15:40:09 aye 15:40:11 ack 15:40:14 ok 15:40:19 sounds good 15:40:26 as usually, thanks for joining ) 15:40:43 and happy Independence Day, us folks! :) 15:40:48 Thansk 15:40:50 thanks 15:40:51 .. US folks .. 15:40:54 :) 15:40:58 ok, bye 15:41:11 #endmeeting