16:00:15 #startmeeting Mistral 16:00:15 Meeting started Mon Aug 4 16:00:15 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:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:18 The meeting name has been set to 'mistral' 16:00:28 hi 16:00:41 hello) 16:00:55 let's wait for a couple of mins for others 16:01:12 hi! 16:01:24 hi 16:02:08 #topic Review Action Items 16:02:20 1. rakhmerov, finish reverse workflow implementation 16:03:03 it's not done yet but I"m close because I've almost finished all the preparations (specs, handler and db models) 16:03:16 #action rakhmerov, finish reverse workflow implementation 16:03:29 2. rakhmerov, get update on integration testing 16:03:30 done 16:03:36 3. rakhmerov, let akuznetsova know that devstack gate keeps failing so that she can find the reason 16:03:56 done, we've figured out the reason, I'm going to fix it this week 16:04:16 #action rakhmerov, fix devstack gate problem (caused by changed in DB layer) 16:04:39 #topic Current status (progress, issues, roadblocks) 16:05:50 my status: last week I worked on specifications (versioning, v1/v2, tests) and DB layer refactoring (switched from dicts, versioning, v2 models) 16:06:06 hoping to get reverse workflow done this week 16:06:36 my status: last week: staying current with Renat’s changes, review, discuss, feedback. 16:06:39 most of the code exists, I just need to carefully move it to the new engine 16:07:05 hi dzimine 16:07:07 I finished with https://blueprints.launchpad.net/mistral/+spec/mistral-mistralclient-integration-tests and almost done with https://blueprints.launchpad.net/mistral/+spec/mistral-cli-integration-tests (wait for merge my commit in tempest) 16:07:33 I worked on openstack-action blueprint, main part is finished now - https://review.openstack.org/#/c/111231/ 16:07:55 dzimine, would be nice to see your feedback on https://review.openstack.org/#/c/111218/ (and Nikolay's too) 16:08:20 This week: look at the yaml syntax for Multiple data blueprint, and may be take a stub on DSL v2 syntax. 16:08:46 thanks, that would be really helpful 16:10:20 any roadblocks from anyone? 16:10:30 issues, questions? 16:11:15 no 16:11:18 ok 16:11:40 from my side, last week I felt I really got stuck with DB layer refactoring 16:12:16 so I would ask everyone to provide an early feedback on https://review.openstack.org/#/c/111218/ 16:12:50 in fact, I realized that the approach used in there leads to interesting things 16:13:00 basically, we need to version almost everything 16:13:22 REST API, DSL specs, db models and even tests 16:13:29 renat as for reverse workflow - if it takes a whole week, I’d punt on it’s full implementaion till later and only see how we conceptually support two types of workflow (DSL, and calls). Which may be done with some stub impl. may be. 16:13:53 I see, yes 16:13:53 rakhmerov: cli and mistralclient too, i guess) 16:13:55 agree 16:14:35 dzimine, what I've been doing so far is related with the whole V2 thing, not only reverse workflow 16:14:50 it will be needed for direct workflow and whatever else 16:15:20 but I agree, we can implement a stub for reverse workflow now and move on to the linear 16:15:24 my comment was on your plans to implement reverse workflow this week 16:15:49 akuznetsova, you're absolutely correct :) mistralclient and CLI will have to be versioned as well 16:16:03 which scares me a little bit but I just don't see other ways 16:16:12 dzimine, ok 16:16:36 keep in mind this refactoring is special, and this time we need to version everythign, after we transition we delete some, right? 16:17:11 after we make sure that at least Solum is happy 16:17:11 yes 16:17:34 when the transition is complete, we surely want to keep a version of API, but old DSL, engine, DB, tests, etc may be gone? 16:17:44 #action rakhmerov, if full reverse workflow takes too long just limit by a stub impl and move on to linear 16:18:32 dzimine, this is actually interesting 16:19:08 even though it's not going to make too much sense in perspective we can actually keep supporting v1 16:19:14 We can currently have stub impl for both reverse and linear, use DSL with one task in both, and figure out ‘external’ mechanics of creating and managing workflows. 16:19:24 because we'll have parallel entities in the code 16:19:48 however, I'm not sure about some parts like engine->executor protocol, for instance 16:20:05 yes 16:20:28 just to make sure... what do you mean by "external" mechanics? 16:21:49 you mean all high-level communications like engine->handler? 16:22:12 yes. 16:22:46 use case: dsl has two workflows, each has a task, types are different, just make sure they are instantiated, parsed, etc. 16:23:26 when they are executed, proper sections go to proper handlers. 16:23:53 yes, ok 16:24:15 np 16:24:45 #topic Open Discussion 16:25:21 guys, are there any other important things you'd like to discuss? 16:25:36 if no, I'd suggest we save our time and finish the meeting earlier 16:26:02 we've got plenty of work to do (at least I do :) ) 16:26:57 I have a question 16:27:16 sure 16:27:19 fire away 16:27:34 how do we test all openstack actions? 16:27:48 ooh, yes 16:27:49 I guess it can be integrated tests 16:27:52 this is a good one 16:28:15 yes, IMO it should be implemented as a part of integration tests 16:28:28 and if yes, we need to extend our devstack 16:28:41 the only issue I see is that devstack doesn't have some components like heat 16:28:52 (I may be wrong though) 16:29:00 yes 16:29:00 probably, we can make a special workflow and run then in integration tests in gate 16:29:08 rakhmerov: it is not true 16:29:22 what exactly? 16:29:29 heat? 16:29:31 akuznetsova, yes :) 16:29:33 ok 16:29:52 rakhmerov: actually, i am not sure about heat, i will check it 16:30:01 please do 16:30:14 heat is one of the main things we need to integrate with 16:30:15 rakhmerov: maybe we can install it separatly 16:30:35 anyway, we need to understand how to install additional services on devstack 16:30:54 I realize it may not be an easy thing to do for every service 16:30:58 IMO: assuming we are using python-clients for heat/nova etc, we don’t need to retest that those clienst work, we need to test that we are invoking them with the right params. 16:30:59 rakhmerov: yes, that's what I said 16:31:38 also: for ideas, check how Heat team is testing nova actions. 16:31:46 dzimine, hm... kind of true, but dunno. 16:31:59 right 16:32:29 I would just mock up the clients and see if we get to calling them. 16:32:35 you know, at least I would have a few integration tests for some typical actions 16:32:45 a couple for Nova, a couple for cinder etc. 16:33:08 I think it depends on how hard it is to write this kind of test 16:33:31 BTW nikolay do you rely on each client or on python-openstackclient? 16:33:33 if it's something hairy to do then yes, it's not worth it 16:33:41 nmakhotkin_: can we discuss you 'openstack action'? I want to know more about your vision and propose how to test it and what to test 16:34:23 dzimine, on each client 16:34:32 thnx 16:34:40 I think at this point it is correct 16:35:17 akuznetsova, don't worry about it for now. Firstly, I think Nikolay should write these tests himself 16:35:35 at least a few most important 16:35:48 then we'll see what it takes and decide if we need more 16:35:58 if yes, then you could take them over 16:36:10 and write more 16:36:13 rakhmerov, +1 16:36:23 rakhmerov: nmakhotkin_ ok 16:37:23 #action akuznetsova_, figure out whether devstack has heat installed out of the box 16:38:10 #action akuznetsova_, figure out how to install additional services (i.e. Sahara) on devstack gate and estimate how hard it is 16:38:25 this is good 16:38:30 anything else? 16:40:02 ok, let's finish for today 16:40:15 thanks to everyone 16:40:19 bye 16:40:28 #endmeeting