16:00:45 #startmeeting Mistral 16:00:46 Meeting started Mon Jan 13 16:00:45 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:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:50 The meeting name has been set to 'mistral' 16:00:53 hi! 16:00:57 hi everyone 16:01:34 let's start our meeting 16:01:44 as usually here's the agenda: https://wiki.openstack.org/wiki/Meetings/MistralAgenda 16:02:52 Hi there) 16:02:57 hi! 16:03:13 we had a long holiday season so there wasn't a lot of activities 16:03:59 hi 16:04:13 generally, right before the holidays we decided to implement some additional things that should be included into PoC 16:04:18 hi gokrokve! 16:04:24 how are you? 16:04:33 doing well. 16:04:38 Thanks 16:05:05 ok ) 16:05:48 briefly describing what these new features are I can say that it's mostly related with DSL 16:06:01 we want to add direct transitions between tasks 16:06:45 as opposed to our current approach where we just define dependencies (similar to makefile) between tasks 16:07:22 we also want to add conditional expressions for both dependency declarations and direct transition declarations 16:07:41 and since we need conditional expressions we'll have to implement Data Flow 16:08:02 here is the etherpad that summarizes all these things: 16:08:06 #info https://etherpad.openstack.org/p/mistral-poc 16:08:42 for now we decided to proceed with option #3 which is a hybrid of dependencies and direct transitions 16:08:57 unless we change this decision today 16:09:36 Lets keep #3 for now. 16:09:45 ok 16:09:47 When dwill you have this implemented? 16:10:21 my estimation was 2 weeks 16:10:25 s/dwill/will 16:10:31 ok 16:10:35 so it means the end of the next week 16:11:11 so, do we have any concerns about new DSL syntax or anything else? 16:11:21 maybe suggestions on how to improve it 16:12:18 #action proceed with option #3 in https://etherpad.openstack.org/p/mistral-poc 16:12:50 while you're thinking I'll tell you briefly about the current status 16:13:19 so now we have implemented the simple model with declaring dependencies between tasks 16:13:32 we have a REST action 16:13:50 we have a very simple demo that demonstrates that 16:14:25 we also have required code to call periodic tasks related to real OpenStack calls 16:14:42 I mean keystone trusts 16:15:12 our QA team has also implemented basic tempest test suite for Mistral API 16:15:36 rakhmerov, can you please tell how to obtain the demo? Is it demo app in mistral repository or something else? 16:15:49 for the last couple of days we've been refactoring our current engine implementation a little bit 16:16:14 yes, tempest tests for Mistral can be found by the following link: https://github.com/Mirantis/tempest/tree/platform/stable/havana/tempest/api/mistral 16:16:15 tnurlygayanov, currently it's a part of the same repository 16:16:26 ok 16:16:35 give me a second, I'll find a link 16:17:09 here it is: https://github.com/stackforge/mistral/tree/master/mistral-demo-app 16:17:38 btw, I was going to request a new repository for this 16:17:55 I thought it would be called like "mistral-samples" 16:18:27 but there was an idea to create a repo "mistral-ext" for all additional things we might want to have 16:18:35 including examples 16:18:53 we can actually make this decision right now 16:19:30 I already request a new repo "mistral-pythonclient", it's being reviewed 16:19:56 requested.. 16:19:58 #info https://review.openstack.org/#/c/63876/ 16:19:59 rakhmerov, python-mistralclient will be more 'OpenStack-like' 16:20:18 wow, I confused the name 16:20:20 ok 16:20:25 it is python-mistralclient, right 16:20:44 it now has -1 but the comment has already been addresed 16:20:55 Jeremy just needs to take a look at it again 16:21:00 I'll ping him today 16:21:24 so what about "mistral-ext" or "mistral-extensions" ? 16:21:49 it can include sample applications, some additional tools maybe 16:21:52 maybe mistral-extra ? 16:22:09 yes 16:22:20 mistral-extensions looks good. 16:23:03 I like it a little bit better too 16:23:10 it looks more explicit 16:23:42 rakhmerov: i'll go back over it 16:23:57 ooh, thanks 16:24:44 there is already existing repo *-extra for savanna 16:25:13 why would we need a separate repo for examples? 16:25:38 because we don't want to mix them with the core project itself 16:25:57 physically it should be a different storage I think 16:26:17 basically, demo apps are clients of Mistral, not a part of it 16:26:28 yes 16:26:31 and we may have many of them 16:27:21 NikolayM, what does savanna-extra contain? 16:28:45 it contains some additional image-elements (or contained before) and there was patch for hadoop swiftFS 16:28:57 ok 16:29:27 so, mistral-extra or mistral-extensions? 16:29:38 no big difference to me 16:30:40 om,there are examples in savanna-extra 16:31:05 It will be great to have plugins in Mistral. 16:31:25 you mean in this new repo? 16:31:29 It is better to have pluggable mechanism at the beginning. 16:31:39 generally, yes, I agree, we were planning to have plugins for Mistral 16:31:47 Col 16:31:50 Cool 16:31:56 ok, I would suggest we proceed with "mistral-extra" then 16:32:11 it will be aligned with savanna naming 16:32:28 ok 16:32:51 #action create new repo "mistral-extra" to move demo applications into it 16:33:36 so getting back to DSL changes 16:33:43 is everyone ok with them? 16:33:55 if yes, we'll start implementing them shortly 16:34:16 we don't have much time, we need to get it done as soon as possible 16:34:47 what about task property names in DSL? 16:35:12 escpecially 'OnSuccess' and 'OnError'? 16:35:15 what exactly? 16:35:17 ooh 16:35:36 ok, initially we suggested just "SUCCESS" and "ERROR" 16:36:37 two sections to describe what we do next in case if a task succeeded or failed 16:36:51 but some folks didn't like "SUCCESS" and "ERROR" :) 16:37:02 and suggested "OnSuccess" and "OnError" 16:37:50 I'm ok with both options, there was just a concern that "OnXXX" means that they are mutually exclusive 16:38:34 and in case we don't have "On" prefix we can define a logic to handle, for example, an error locally without jumping over tasks in a workflow 16:39:05 but to me it seems to be similar 16:39:27 "OnSuccess" and "OnError" may be more readable 16:40:00 rakhmerov: I agree that 'onXXX' is more readable 16:40:07 and semantically it can mean both "mutual exclusive" or "sequential" 16:40:20 joel_c1, glad to see you here :) 16:40:23 thanks, yes 16:41:51 so we decided then? 16:42:13 "OnSuccess" and "OnError" 16:42:17 ok 16:42:41 I agree with 'OnXXX' 16:42:59 #action proceed with names "OnSuccess" and "OnError" for task sections to describe what to do in case of success and failure 16:43:27 guys, is there anything else that you would like to discuss today? 16:44:19 if no, I would suggest we finish for today. Looks like we have a plan to go with 16:44:54 alright, thanks to everyone 16:45:00 I'll see you next Monday 16:45:05 #endmeeting