16:00:20 #startmeeting mistral 16:00:21 Meeting started Mon Jun 16 16:00:20 2014 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:24 The meeting name has been set to 'mistral' 16:00:30 hi 16:00:59 hi 16:01:07 how are you? 16:01:17 doing good. how about yourself? 16:01:28 still alive :) 16:01:34 hi all 16:01:39 hi Dmitri 16:02:02 so let's begin 16:02:54 renat welcome back :) 16:02:58 thanks 16:03:00 can we start with quick member-by-member update today? 16:03:32 I read the previous meeting log so am a little bit aware of what you guys were doing 16:03:50 I’ll start as there’s little to update: didn’t have time to continue ‘start-task’ blueprint last week unfortunately, so only did reviews 16:04:11 ok, that's fine 16:04:34 dzimine, do you see any potential problems with this task? 16:04:51 no. it’s just a bunch of updates all over the place 16:04:58 one thing I'm worried about is that we must be really careful about changing our API 16:05:06 I already have the draft impl. 16:05:20 let’s talk about API later today. this is a key topic. 16:05:21 Angus warned us many times that we should be carefully versioning our API 16:05:39 ok, sure, let's postpone it 16:05:50 m4dcoder? 16:05:53 proposed design for https://blueprints.launchpad.net/mistral/+spec/mistral-engine-executor-protocol on ML. also had some questions on parallelism referenced in the bp. waiting for responses. i have some other priority work to do this week so probably won't pick up this bp work until next week. 16:06:41 I see 16:06:51 could you please find a link to this thread? 16:07:06 there's 1500 emails in my inbox and I didn't process them yet ) 16:07:07 http://lists.openstack.org/pipermail/openstack-dev/2014-June/037547.html 16:07:17 thanks a lot 16:07:20 np 16:07:46 #info Winson's desing for engine-executor protocol: http://lists.openstack.org/pipermail/openstack-dev/2014-June/037547.html 16:08:08 I'll look at it tomorrow morning and reply to you 16:08:17 thanks! 16:08:18 that's pretty important for us 16:09:15 Nikolay, are you with us today? 16:09:51 he's probably not 16:10:10 Timur also said he couldn't make it to be at the meeting 16:10:22 so, as far as myself 16:10:53 is Angus around? 16:11:29 I spent most of the time on reading emails, BP comments and talking to folks to find out all the news 16:11:56 and I also started thinking on the big engine refactoring that we agreed on at the summit 16:12:21 have some ideas written down but nothing is really shaped out yet 16:13:21 my plan is to spend some time researching ansible and other wf technologies first since I feel I have lots of gaps in my awareness 16:13:47 I also reviewed several patches today and sent a couple of my own patches 16:14:35 btw, dzimine, I agree with you suggestion to hold on making our devstack gate voting 16:15:15 there's a patch already but it'll be hanging for a while with -1 till we see it's comfortable to activate it 16:15:41 so anything else for now? 16:15:58 I would switch to open discussion and talk about API 16:16:14 unless we have anything else: roadblocks, questions etc. 16:16:31 API is the #1. 16:16:37 ok 16:16:42 #topic Open Discussion 16:16:52 ok, fire away Dmitri 16:17:07 what are your thoughts? 16:17:19 Just like u, I spoke with Angus: they’re ready to use Mistral and once they do we can’t break things. 16:17:28 But, we are making breaking changes on API. 16:17:29 yes 16:17:36 which ones? 16:18:01 start-task, workflow-in-workflow, and exposing worklfows, triggeres, actiosn as 1st class entities. 16:18:20 oooh, but it's all in progress now 16:18:24 which is good 16:18:31 So, how much of these can we do before we freeze the API? 16:18:36 I believe so far we didn't break anything 16:19:07 I would limit those changes in v1 by start-task 16:19:26 other things should be done as a part of the next API version 16:19:52 What is the deprecation story? 16:19:54 because seemingly start-task thing is almost backwards compatible, am I right? 16:20:25 I mean "task" parameter could be just ommitted 16:20:32 deprecation? 16:20:42 you mean "requires"? 16:22:11 yes ‘task’ can be omitted and ignored in API call. Must present in DSL, though. 16:22:28 if you're talking about "requires" I'm ready to deprecate it now. However, we have to run it by our current stackholders: Fuel and Solum 16:22:50 yeah, DSL will slightly change 16:23:20 which is bad but I think we can afford this change now 16:23:51 Here’s a suggestion: include start task and deprecate require’ in v1, and do the rest in v2. 16:24:07 agree 16:24:27 An alternative would be to ask Angus to wait and help with the API (which he offered) and do the API cleanup in V1. 16:24:34 but again, let's make sure we won't steal a goodie from FUEL and SOLUM 16:24:40 I mean "requies" 16:25:17 that's a good alternative 16:25:25 let me talk to him tomorrow 16:25:34 I wonder if they can wait. 16:25:43 I just need to sync up with him and see what he's up to 16:25:49 yes, dunno 16:26:03 with 2 versions of API we’ll need to support 2 sets of tests, etc, it’s too early. If they only can wait for a bit. 16:26:09 anyway, I wouldn't include other changes in V1 like multiple workflows etc. 16:26:21 only start-task and "requires" deprecation 16:26:45 yeah, good point about tests and whatever else 16:27:23 ok, so I think we have an agreement on this 16:27:53 the only thing I would suggest is that we shouldn't hurry with this 16:28:11 we gotta be really really careful and think twice 16:28:32 and discuss things in ML 16:29:03 m4dcoder, just recalled I had a question for you 16:29:12 it's minor but I'm just curious 16:29:24 shoot 16:29:27 why did you rename mistral.conf.example to mistral.conf.sample? 16:29:45 generate_sample.sh generates sample file with this name. 16:29:49 was there any strong reason or it was just a preference? 16:29:57 ooh 16:30:00 also if we use check_todate.sh, it's looking for that file. 16:30:24 more consistent then preference. 16:30:25 ok, so it's sort of a standard naming in OpenStack, right? 16:30:28 yep 16:30:33 ok, cool 16:31:02 I'm just asking because something got broken because of that but that's fine, we fixed it 16:31:23 cool 16:31:24 and I also renamed other example files in this manner too 16:31:30 ok 16:32:05 dzimine, a question to you 16:32:11 fire 16:32:35 did you already assigned all the BPs to your folks as you planned about 3 weeks ago? 16:32:59 so that I know who is supposed to do what 16:33:24 in terms of amount of time you already told me so I just would like to know some detailes 16:33:25 no: I am supposed to do this but I only do once they’re available to pick it up. 16:33:44 ok 16:34:09 as far as I understand, Manas is not available for now right? 16:34:44 and Kirill very little 16:34:57 no for Manas, yes for Kirill. 16:35:16 alright 16:36:12 btw, I had a discussion with the folks today and told again that we should be more open to you 16:37:26 yes, thanks: and not just to us but to the community. 16:38:28 yes, right 16:39:08 did you see the discussion on fuctiontests? 16:39:52 nope 16:39:55 in ML? 16:40:00 etherpad. 16:40:20 ML has a link, https://etherpad.openstack.org/p/MistralNewTestsDesign 16:40:30 can you include the link pls? 16:40:32 ok 16:41:43 is there anything that's worth some special attention or it's just FYI? 16:42:06 The attempt is to make as much of functional tests EASILY runnable by developers, the smaller subset which require OpenStack can be run with devstack. Once we are there, we can turn the devstack gate on. 16:42:25 I see 16:42:45 I want to avoid the situation when there are some tests whic you can run on dev box (or takes too much effort to run), and they fail the gate. 16:43:03 well, assummingly we should have two test sets: OpenStack related and OpenStack free 16:43:07 And, if we have them easy to run, we can chage the tests with the code. 16:43:47 sure, I totally agree with this 16:43:53 Yes that’s the proposal. Now it’s not separated yet: all API tests assumed OpenStack related, but most API calls have little to do with OpenStack. 16:43:57 it would make the process more agile 16:44:17 yes 16:44:24 So we all are in general agreement, we only need to give this the right priority. 16:44:32 let’s check with Timur. 16:44:47 ok 16:45:15 btw, we need to start getting Sergey Murashov more and more involved into this 16:45:39 he's going to replace Timur almost 100% 16:46:11 alright 16:46:23 anything else for today? 16:47:21 then let's finish the meeting 16:47:29 thanks guys for joining today 16:47:30 ОК 16:47:36 cheers. 16:47:48 bye 16:47:49 I'll see you (virtually) soon 16:47:52 bye 16:47:56 #endmeeting