16:00:40 #startmeeting Mistral 16:00:41 Meeting started Mon Feb 3 16:00:40 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:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:44 The meeting name has been set to 'mistral' 16:00:45 hi guys 16:01:10 hi :) 16:01:25 hi, how are you? 16:01:33 hi 16:02:09 hi Stan 16:02:37 dzimine, welcome to our team! 16:03:22 ok, let's begin 16:03:23 thanks! 16:03:28 Hi there! 16:03:37 hi 16:03:39 Hi 16:03:47 hello 16:03:52 hi JoelC! Glad you're here 16:03:59 hi all! 16:04:02 :)) 16:04:18 rakhmerov, thanks. 16:04:18 hi 16:04:47 ok, Dmitri. Usually we just walk over agenda items and discuss them 16:04:58 sure 16:05:06 the first one is previous action items 16:05:25 so 16:05:33 #topic Action Items 16:05:36 write a simple demo web application that should be deployed on an instance that Mistral will run 16:06:17 the description is not really clear I think 16:07:09 so it is in progress - it it a web application, which should "do something" on API calls 16:07:20 so the demo scenario is supposed to include a web app deployed on a VM which Mistral is going to send a request to 16:07:27 yes, right 16:07:29 ok 16:07:53 and the second AI was: tnurlygayanov, prepare an image with simple demo web app preinstalled on it 16:08:11 which obviously depends on the first one :) 16:08:19 yes 16:08:19 and hence it's in progress too 16:08:21 ok 16:09:12 btw, I forgot to point to the agenda itself 16:09:15 #info https://wiki.openstack.org/wiki/Meetings/MistralAgenda 16:10:02 do we have a demo scenario described somewhere ? https://wiki.openstack.org/wiki/Mistral/POC says "not finished", MB there's etherpad on it? 16:10:28 so the next topic is going to be DSL and its capabilities. Since we now have new contributors we need to discuss it again 16:10:42 and folks apologize in advance for asking many 101 questions while ramping up. 16:10:45 dzimine, unfortunately this page is outdated 16:11:09 it's ok, don't hesitate to ask 16:11:53 so the best way to look at DSL now is to go to https://etherpad.openstack.org/p/mistral-poc 16:12:26 There is a section called "Complete DSL example" 16:12:41 so we can use it as a starting point for the discussion 16:13:58 dzimine, I know you had some questions and suggestions on how to modify it 16:14:52 would please share your ideas? 16:15:06 there are 3 levels of questions 16:15:14 I'd suggest we concentrate on main features rather than syntax for now 16:15:41 because we should agree on what Mistral should have in terms of functionality first of all 16:15:49 1) overall structure - the open question there is do we want to mix triggers and workflows together 16:16:27 2) the key capabilities of workflow, how it reflects in DSL 16:16:43 3) syntax (and as rakhmerov said it's less important) 16:17:06 ok 16:17:35 and I sense once we begin arguing on 'which is better' we'll need to agree on criteria on what means better. 16:17:47 But you might have agreed on that already, is there a reference? 16:17:57 1) This depends on what do you mean by mixing 16:18:16 dzimine, what reference do you mean? 16:19:08 reference on criteria which we may use to choose, for instance, why option 2 is better than option 1 in the mistral-poc example 16:19:23 ooh 16:19:59 1) I mean, the same definition file contains workbook and event(s) on which it gets triggered. 16:20:46 there may be many events which can trigger the same flow. Including manual 16:20:46 when we were discussing that we just agreed that option 3 is better because it is a superset of 1 and 2, and we have usecases for both "requires" and direct transitions 16:20:46 yes, I got it 16:20:57 let's discuss that 16:22:09 I feel that all the 40 minutes we have we're going to spend on DSL discussions. So that's fine. It's the most important part 16:22:09 ok, what would be your comments here? 16:22:12 1) Triggers and workflows are all parts of required input for Mistral. Mistral does not deal with files so you cannot split it into separate files. 16:23:02 side note - it might be a good idea to schedule a voice meeting 16:23:32 you would prefer to keep events and workflow separately? And if yes, can you please explain why 16:23:33 IMO we can take 1) mixing events and workflows in the same definition into email discussion 16:23:33 but shortly, the reason is reuse: 16:24:52 to enable creating worklfows that can be triggered by multiple events, some unknown in design time. 16:24:53 a workflow can be triggered by cron, ceilometer, manually, or by another flow 16:24:53 yes 16:24:54 currently, even if we have some events configured in a workbook we can still reuse it 16:24:54 in the current design if we put up exactly the same task sequence, with two different triggers, it will be two distinct workbook entities. 16:24:54 we can always start a workflow via REST API call 16:26:00 yes, and therefore keeping the event inside workflow even if it doesn't represent all the events which can trigger this flow, is redundant and confusing. 16:26:17 dzimine: you can have several triggers for the same workflow without repeating workflow twice 16:27:58 it can convey a false impression that the flow is triggered by the only events that are described in event section. 16:27:58 ok, what would be your suggestion here? 16:27:58 than, if we want to update the triggering condition, we modify the workflow, even though the actual workflow is not modified. 16:28:18 I think of introduce an event-workflow mapping, and REST API that manifests it. 16:28:19 stanlagun, yes, I think we need it 16:28:53 let's for now just capture this point of events as part of workflow definition as a discussion point 16:29:41 ok, sure 16:34:46 I think it's an interesting topic, I believe there's much more to discuss on that 16:35:42 #action Discuss separation of events(triggers) and workflow definition in the mailing list and other channels 16:35:42 stanlagun I want to understand this better - "have several triggers for the same workflow without repeating workflow twice", may be I missed something. Let's discuss later. 16:36:07 ok 16:42:34 ok 16:42:34 what about key capabilities? 16:42:34 it was #2 16:46:16 back to criteria: it's good that #3 is a superset, but it implies the criteria we use for choosing it is "we prefer the most generic solution" 16:46:16 no, not only this 16:46:16 we also see use cases for both capabilities 16:46:16 unfortunately, we don't have much time to describe all of them right now 16:46:16 but we can take it offline 16:46:16 what is the use case for option #2 which is not covered by #1? 16:46:16 ok, we can take it off line 16:46:16 so, do you have any suggestions on DSL capabilities? 16:46:16 maybe you could describe some key things that you would like to see in DSL 16:46:17 so that at least we could capture them 16:46:17 any dsl which produces direct graph of tasks and links inputs to outputs of previous tasks is a good input to workflow language. 16:52:53 so how would it affect the current DSL design? 16:52:53 the 3 options out there show different semantic approaches to doing it. 16:52:54 you mean we should rather concentrate on data? 16:52:54 because you said "links inputs to outputs" 16:52:54 answering your last question: whenever we have a conditional logic in a workflow it's much easier to represent it imperatively (option 3). If we were unable to send an email we jump to the corresponding task 16:52:54 Well you guys are putting me on the spot. I have the least context on the project and miss on many discussios and decisions you've made earlier. So whatever I express strong opinion it can and will come across as ignorant and arrogant, and I don't mean it tis way :-) 16:52:54 With this: 16:52:54 we will need some expression for workflow primitives, depending on engine capabilities. 16:52:54 E.g., conditions. 16:52:54 or repeats/loops 16:52:54 ok 16:52:54 once we agree what the engine must support at the minimum (I say, conditions and loops) 16:53:43 we can talk about how to express them in DSL. 16:53:43 ok 16:53:43 The three approaches to express condition are 1) upstream task (current) 2) downstream task (ansible doing it) 3) separate primitive task (many traditional wf engines) 16:53:43 I just thought DSL would exactly reflect what engine should do :) So it's kind of opposite approach here 16:53:43 oh, sorry, I mean exactly the same. DSL reflects engine's capabilities. 16:53:43 yes 16:53:43 it's just how exactly it expresses them? and the same simple capabiltiy - say condition, can be expressed differently in DSL. 16:53:43 so I was thinking it's ok that we're discussing DSL instead of what engine should do 16:53:43 ok 16:53:43 so probably we need to take it offline also 16:53:43 #action Discuss key DSL capabilities in mailing list and other channels 16:53:44 we implicitly agreed that the engine can do 1) sequential flow 2) parallel flow 3) data passing / flow 4) conditions 5) loops 16:53:44 and may be joins (point to discuss) 16:53:44 yes 16:53:44 so engine capabilities are all agreed, right? something to add? 16:53:44 guys, what if we schedule hangouts for tomorrow 8 PST (16.00 UTC) ? 16:53:44 8:30? 16:53:44 because I feel that we have a lot of things to discuss 16:53:44 8.30 would be find to me too 16:54:36 and folks it's an unfortunate cost of bringing someone late to the discussion. if some things are already decided and closed just let us know 16:54:36 dzimine, it's totally fine 16:54:36 I mean, believe me we'll have tons of arguments and IMHO it's a normal thing :) 16:54:37 and no, it's not decided, your opinion is very important for the team. We just need to make sure to consider all your suggestions and discuss them 16:56:09 #action Discuss DSL syntax 16:56:10 ok, I'll schedule hangouts 16:57:03 "we also see use cases for both capabilities" - can you share the link if you have it or describe them if you don't have them written down yet? 16:57:03 please add as an action 16:57:35 ok 16:57:35 #action Describe use cases for option 1 and option 2 in https://etherpad.openstack.org/p/mistral-poc 16:58:08 ok, we're about to finish 16:59:10 I would like we to agree on DSL as soon as possible 16:59:10 ideally this week 16:59:17 I personally think we don't have too many things on which we disagree 16:59:38 it's rather a terminology and other stuff like that 16:59:42 see you tomorrow on hangouts 16:59:42 #endmeeting