16:00:03 #startmeeting Mistral 16:00:04 Meeting started Mon Jan 20 16:00:03 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:07 The meeting name has been set to 'mistral' 16:01:33 Let's start? 16:01:59 Hi. 16:02:10 morning ) 16:02:21 Hi 16:02:35 #topic Review AIs 16:03:01 so last we had several AIs 16:03:04 1. proceed with option #3 in https://etherpad.openstack.org/p/mistral-poc 16:03:13 we're currently implementing it 16:03:41 additionally, we've added a complete DSL example at the end of this document 16:03:52 I was planning to discuss it today too 16:04:41 I think it contains some bugs now, I'll fix them today. But generally, this is the scenario that we will be targeting for 16:04:48 we need to make it work 16:05:14 Hi 16:05:20 hey 16:05:31 the second AI: 16:05:39 2. create new repo "mistral-extra" to move demo applications into it 16:06:12 it's almost done. We had a couple of technical issues with the new repo but it's fine now. 16:06:18 #info https://review.openstack.org/#/c/67860/ 16:07:07 and btw, this repo was approved very quickly, I guess within a week 16:07:16 which is good 16:07:37 3. proceed with names "OnSuccess" and "OnError" for task sections to describe what to do in case of success and failure 16:07:48 that's what we're doing now 16:08:33 but there's a suggestion to use "on-success" and "on-error" to distinguish better between task names and keywords 16:09:29 if you also take a look at Complete DSL we've added "on-finish" which means "do it in any case no matter if it's a success or a failure" 16:09:53 any questions/comments on that? 16:11:40 alright 16:11:43 no questions 16:11:54 and it will possible to add something like 'on-exception', 'on-stop' and etc? 16:12:22 well, yes, but I guess "on-exception" is the same as "on-error" now 16:12:30 or you mean something different? 16:13:54 Another question how to find that it is 'on-exception', not failure? 16:14:19 as a general comment, we should try to keep DSL simple, we've already gone far beyond our initial requirements ) 16:14:45 not failure? 16:14:46 'on-exception' - rollback to avoid 'partial finished' tasks 16:15:03 ok 16:15:53 yes, I mean I'm just trying to understand if "on-error" and "on-exception" are different things in your understanding 16:16:44 I think they are the same 16:16:49 ok 16:16:57 Timur? 16:17:41 from my standpoint, I think it would make sense to call it "on-exception" if we had information about exception type so that we could handle different exceptions differently 16:18:12 for now we just called it "on-error" meaning no matter what happened, something went wrong 16:18:17 Yes, I agree 16:18:27 although, it may be a philosophical thing ) 16:18:45 'on-exception' for internal exception ) 16:18:53 yes 16:19:17 nmakhotkin, so could explain again your question "how to find that it is 'on-exception', not failure?" 16:19:21 not sure I got it 16:21:17 exception is when you cannot reach the service. error is when service says so (like 404 error code). Not sure we need to distinguish errors and exceptions for now 16:21:26 I mean a task state, how we can know whether we receive exception state or failure state? 16:21:50 Hmm, ok 16:22:39 stanlagun, agree with you 16:23:25 I suggest having jous one OnError and later provide additional data on what type of error it is. It may be more then those 2 types of errors for some actions 16:24:00 right 16:24:02 agree 16:24:45 so let's spend some time for discussing DSL example 16:25:03 #topic Discuss Complete DSL example (https://etherpad.openstack.org/p/mistral-poc) 16:25:24 currently it contains error, not everywhere it's a valid YAML ) 16:25:32 which is my fault, I'll fix that today 16:26:05 additionally, stanlagun suggested some changes for wait conditions 16:26:12 in red 16:26:20 I tend to agree with them 16:28:21 my initial suggestion was: 16:28:25 waitForIp: 16:28:25 action: std:wait 16:28:25 parameters: 16:28:25 delay: 3000 16:28:25 max: 5 16:28:25 on-success: checkIP 16:28:26 on-error: sendCreateVMError 16:28:39 and his: 16:28:40 waitForIp: 16:28:41 action: std:repeat 16:28:41 task: doSleep 16:29:06 I think the second option is better since it splits responsibilities better 16:30:18 if you guys have any other questions on that DSL let's talk about it 16:30:32 no better time but the present :) 16:31:28 one thing that bothers me is preparing an image with a python program starting automatically on it when an instance runs 16:31:45 tnurlygayanov, I think you're the best person to talk about it to 16:32:13 do you think it will be easy to do for our demo scenario? 16:32:31 how much time may we need for that? 16:36:01 Timur, you here? 16:37:40 ok, any other concerns on what we've come up with? 16:37:49 yes 16:37:55 ) 16:38:20 hm 16:39:10 ok, I think we can do this for demo 16:39:18 yes, so we'll just need to create an image (say ubuntu) with a python web application on it that must run automatically 16:39:22 perfect 16:39:52 we can do this with Murano or Heat ) 16:39:55 how would you estimate the efforts required for that? 16:40:08 with Murano it is 5 minutes ) 16:40:12 excluding the app itself 16:40:14 :)))) 16:40:44 so, you want just Ubuntu with Web Server as a result? 16:40:46 ok, it's even better that I thought 16:40:52 yes 16:41:10 I thought it would be the whole 10 minutes ) 16:41:12 ok, we have the Apache Linux Server in Murano and it is already ready to deploy. 16:41:21 kidding 16:41:35 ok, that's good, so looks like it's not really a problem 16:41:50 ok, guys, any other questions/concerns? 16:42:32 please take a look again at this complete example when you have time. We need to make it shine and use as a target scenario for PoC 16:43:00 #topic Current PoC status 16:43:08 So, I'll be quick on that one 16:43:42 we're currently working on the new requirements, finished serious refactoring in our engines (local and scalable) 16:44:18 so in my understanding we'll be able to finish it not earlier than in 1.5-2 weeks 16:45:13 besides, we now have repos for python-mistralclient and mistral-extra where we will keep our demos and additional tools 16:45:39 #top Open discussion 16:45:47 #topic Open discussion 16:46:17 btw, I'd like to capture 2 action items 16:46:56 I suggest to discuss demo scenario ) 16:47:26 #action, nmakhotkin, write a simple demo web application that should be deployed on an instance that Mistral will run 16:47:28 sure 16:47:31 sec 16:48:07 #action tnurlygayanov, prepare an image with simple demo web app preinstalled on it 16:48:12 ok, go ahead 16:48:21 what would you like to discuss? 16:49:04 what will mistral do with Web Server? Do we plan to deploy or perform backup? 16:49:15 ok 16:49:31 I was thinking about something like backup first 16:50:03 but honestly, I just didn't come up with something interesting that would demonstrate our new DSL capabilities 16:50:18 even though we could do something with backups 16:50:20 so 16:50:32 instead, I'm now suggesting the following scenario 16:50:47 1. create a VM 16:50:57 2. wait till it's really created 16:51:11 3. run a job on the VM 16:51:44 which will be just sending HTTP request to a python program installed on the VM (what I called web application earlier) 16:52:03 4. merge results into execution context 16:52:21 5. destroy the VM 16:52:53 and that should happen periodically 16:53:13 so this scenario will demonstrate all we want 16:53:22 is it requred to have the python-based web server? 16:53:44 well, in general no 16:54:10 we just need to have a REST endpoint on the VM that does something 16:54:17 from Mistral perspective 16:54:37 it could be implemented either with python or in a different way somehow 16:54:43 do we plan use Nova API for manage VMs? 16:54:51 yes, we do 16:55:05 there will be two request to Nova 16:55:13 createVM and destroyVM 16:55:21 ooh, even three 16:55:25 and one more question: how we will detect that VM is ready for step3 ? 16:55:39 also getVMdetails (in order to check IP address) 16:55:45 yes ) 16:55:49 just answered :) 16:56:02 any concerns on that? 16:56:34 in my understanding that should work, but maybe I'm misssing something 16:56:55 just answered :) - we will just send requests for Web server and wait valid response? ) 16:57:27 ok, there two parts 16:57:37 first, we need to wait till VM is up 16:57:53 for that we'll be sending requests to Nova periodically 16:58:05 with some delay up to say 5 times 16:58:31 and the second part is we'll send a request to do some useful job on that VM 16:58:34 so, probably some timeout will be more usefull that 'times count' 16:58:41 and that's why we need this web app 16:58:48 yes 16:58:59 ok, guys, I think we need to wrap up 16:59:00 :) 16:59:18 let's continue offline or next time 16:59:27 bye 16:59:34 #endmeeting Mistral