16:00:17 #startmeeting Mistral 16:00:18 Meeting started Mon Nov 18 16:00:17 2013 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:21 The meeting name has been set to 'mistral' 16:00:28 hi 16:01:13 let's have another community meeting 16:02:10 meeting agenda for today: https://wiki.openstack.org/wiki/Meetings/MistralAgenda 16:03:32 Hi 16:04:06 hi 16:04:49 ok, let's quickly review the previous action items 16:04:59 #topic Review action items 16:06:57 rakhmerov, akuznetsov, stanlagun, tsufiev, keep working on DSL/API Mistral specification and include all features discussed at the summit 16:08:13 it's still in progress 16:08:33 I think we need to speed this up this week 16:09:01 yes, definitely :) 16:09:04 according to our Roadmap it should be done by Nov 25 16:09:20 yeah 16:10:03 so, in fact, we need to accomplish this in 2-3 day to have some time for discussions reviews 16:10:37 I'm going to contribute a significant part of my time for that starting tomorrow 16:11:18 ok, next item 16:11:34 rakhmerov, publish detailed description of "Long-running business process" use case on wiki 16:11:36 done 16:12:09 #info https://wiki.openstack.org/wiki/Mistral/Long_Running_Business_Process 16:12:18 next 16:12:38 rakhmerov, create a list of Blueprints for Mistral features 16:12:43 it's basically done 16:13:06 I created a list of blueprints that reflect everything we've discussed so far 16:13:33 #info https://blueprints.launchpad.net/mistral 16:13:38 next item 16:14:06 ativelkov, collect the info about use case related to setting up a network 16:14:15 in progress and it's not a high priority 16:15:01 akhmerov, put together AIs and agreements achieved in HK and publish them in mailing list 16:15:08 done 16:15:26 I put everything into blueprints 16:15:36 cool ) 16:16:08 and I'd ask you to validate them and share your feedback 16:16:09 I suggest to specify the priority for each blueprint 16:16:22 yeah, right :) 16:17:03 #action rakhmerov, specify priorities for blueprints 16:17:10 thanks 16:17:10 and... looks like I have no access to edit or add some blueprints... and I belive that other peoples too ) 16:17:24 need to allow access to the launchpad project 16:17:58 ok, sure 16:18:00 will do 16:18:33 #action grant access to publish blueprints at Launchpad to other participants 16:18:39 ok, next item 16:19:00 gokrokve, igormarnat, akuznetsom review Roadmap and add whatever you think needs to be added in there 16:19:05 basically done 16:19:16 next item 16:19:34 rakhmerov, share Roadmap with the community to start discussing it 16:19:38 done 16:20:01 #info https://wiki.openstack.org/wiki/Mistral/Roadmap 16:20:18 #info https://etherpad.openstack.org/p/MistralRoadmap 16:20:50 I think we'll be making some changes to it but it pretty much reflects our current vision 16:21:32 if you any comments on that we can discuss it 16:21:48 rakhmerov, akuznetsov, NikolayM review https://github.com/airbnb/chronos and http://mesos.apache.org/  with regard to storing and executing distributed tasks 16:21:58 it's in progress 16:22:45 I think we can spend some time (not too much) this week just to get familiar with those things on a high level (functionality, architectural approach) 16:22:54 I am not sure that it is suitable for us, because this projects has dependencies on Apache Zookeeper 16:23:12 ook 16:23:44 did you have a chance to look at them? 16:23:49 how detailed? 16:24:33 ok, we can get back to it later 16:24:38 last item 16:24:46 rakhmerov, kuznetsov, harlowja clearly describe the high-level separation of functionality between TaskFlow and Mistral in terms of addressed use cases 16:24:58 we worked on that pretty actively 16:25:14 had lots of discussions and we create a good etherpad 16:25:34 #info https://etherpad.openstack.org/p/TaskFlowAndMistral 16:26:11 I think it's mostly clear what's in common and what the differences are between these projects 16:26:54 we pretty much agreed that they have some overlap but the processing models are significantly different 16:27:08 and applicable for different use cases 16:27:42 again, if you have any additional thoughts please write them in there (etherpad) 16:28:01 so ok, we have a few more things to discuss today 16:28:07 let's move on to the next topic 16:28:38 #topic Mistral PoC scope 16:30:12 I created a blueprint for Mistral PoC at Launchpad 16:30:29 where I listed out on a high level what needs to done 16:30:41 hm, Launchpad seems to be down for me 16:31:00 could you guys try to open https://blueprints.launchpad.net/mistral? 16:31:15 it works 16:31:20 works 16:31:36 hm, problems on my side 16:31:46 I just subscribed to the scheduling bp 16:31:57 ok 16:32:03 ok, works for me now 16:32:05 here it is 16:32:08 #info https://blueprints.launchpad.net/mistral/+spec/mistral-poc 16:32:50 please take a look at it and let us know if you have suggestions on what should be included/removed 16:33:27 we plan to use two cli clients? 16:33:56 that's a different topic :) 16:34:07 but possibly yes 16:34:16 so, it is about blueprints :) 16:34:23 and it's not going to be in PoC most likely 16:34:36 tnurlygayanov, yes 16:35:24 ok ) 16:35:49 the term "CLI" for the second one (for launching a worker process) may not be very good but basically the idea is to create a command line tool to simplify configuring and launching a worker process 16:35:55 we can probably move some information for each blueprint on the wiki 16:36:08 we have it there :) 16:36:36 #info https://wiki.openstack.org/wiki/Mistral/Blueprints 16:37:00 they currently don't contain much but we'll be populating them as we work 16:37:45 cool 16:38:26 well, I'm looking at the blueprint now and I would add one more item: 16:38:44 do we have anything for discussion? When we plan to start write the first line of code? ) 16:39:01 demo worker 16:39:20 well, we already have several :) 16:40:39 i suggest not to use word 'worker' 16:40:46 but today we're supposed to start writing it really intensively 16:41:02 stanlagun, what would be your suggestion? 16:41:17 demo app 16:41:30 I don't like it either since it may confuse people (as if Mistral had dedicated workers) 16:41:31 hm.. 16:41:39 worker means something dedicated 16:41:44 more like in celery 16:41:53 yes, I know 16:42:00 we have blueprint for worker cli, but have no blueprint for wroker. What is it? 16:42:23 *worker 16:42:26 well, a worker is supposed to be created using worker cli :) 16:42:52 worker=worker cli=demo app? 16:42:56 like stanlagun said, "worker" is not something specific to Mistral 16:43:11 its confusing 16:43:14 yes, something like that 16:43:28 we can call it in another way 16:43:47 I just think "demo app" doesn't reflect it's meaning 16:44:05 what this "worker" will do? 16:44:19 it will process task actions 16:44:47 coming from Mistral via some channel like rabbit or HTTP 16:45:05 "action handler" or "handler" may be? 16:45:31 usually Mistral client app is the worker. Demo app is just an app that uses Mistral. And it is worker for its own tasks 16:46:02 The point is that app is not about task handling as it is not its main purpose 16:46:19 stanlagun, I agree but I believe that may be confusing for people too :) 16:46:41 hm... 16:46:43 thinking 16:47:04 how about "handler application"? 16:47:07 Just don't want people to think that they need to craft special workers every time 16:47:07 i'd suggest call it 'demo client' 16:47:19 because this app is also a client for Mistral 16:47:21 I just want to make it clear that this is something that handles actions 16:47:21 so, it is mistral-agent ) 16:47:33 app is too general 16:48:11 tsufiev, "because this app is also a client for Mistral" is not really true 16:48:24 it may be but not necessary 16:49:14 ok, let's postpone take it out of this meeting 16:49:50 #action rakhmerov, stanlagun, come up with a good name for "worker" (so that it wouldn't be confusing) 16:49:58 #topic Blueprints 16:50:16 I think we've been discussing that for a while 16:50:22 The difference is that demo app does something valuable and uses Mistral to achieve its goal. It handles task actions for that matter. Handler app is the app dedicated to task handling that has no business value of its own 16:50:51 well 16:50:59 consider the following scenario 16:51:31 say we've created a PoC and CLI to work with Mistral 16:51:50 so that I can cal: mistral upload mytaskgraph.yaml 16:52:16 mistral start-workflow 12 "create_env" 16:52:32 I don't have anything what you call app here 16:52:41 I'm just using CLI to start my workflow 16:53:33 I agree it's not something given from the real life but anyway, moving forward we'll have use cases like this 16:53:33 but who will do the actual work of creating env in that case? 16:53:35 I think there cannot be generic client that can start just any given workflow 16:54:33 Apps know how to handle some specific workflows that does something meaningful. So that would be not just CLI but a normal app 16:54:41 tsufiev, it can be heat or anything else that we can access via AMQP or HTTP 16:55:12 well it can be true in some cases 16:55:16 but not for now 16:55:27 stanlagun, I see your point here 16:55:54 anyway yiu cannot make generic CLI client. Just an app for special cases of workflows 16:56:26 not sure I'm understanding you here, seriously :) 16:56:54 why can't we have CLI that we could use just to, for example, upload a start a workflow? 16:57:24 the work may be done by real applications but a point where we start it can be CLI easily, why not? 16:57:33 I'm not saying it's a typical use case 16:57:46 but in some cases we can use it 16:57:53 we could have. But this would be management colnsole :) 16:57:58 console 16:58:18 :) 16:58:34 we don't really need management console for PoC 16:58:35 yes, but for me it would be convenient to have CLI 16:58:43 management CLI 16:58:46 anyway 16:58:54 yes, agree here 16:58:58 Mistral admin 16:59:05 I was talking actually not about PoC, sorry 16:59:07 ok 16:59:08 1 min 16:59:18 let's wrap it up 16:59:32 I'll see you soon guys, bye 16:59:37 #endmeeting