16:00:40 <rakhmerov> #startmeeting Mistral
16:00:41 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:44 <openstack> The meeting name has been set to 'mistral'
16:00:45 <rakhmerov> hi guys
16:01:10 <dzimine> hi :)
16:01:25 <rakhmerov> hi, how are you?
16:01:33 <stanlagun> hi
16:02:09 <rakhmerov> hi Stan
16:02:37 <rakhmerov> dzimine, welcome to our team!
16:03:22 <rakhmerov> ok, let's begin
16:03:23 <dzimine> thanks!
16:03:28 <tnurlygayanov_> Hi there!
16:03:37 <JoelC> hi
16:03:39 <dteselkin> Hi
16:03:47 <akuznetsova> hello
16:03:52 <rakhmerov> hi JoelC! Glad you're here
16:03:59 <rakhmerov> hi all!
16:04:02 <rakhmerov> :))
16:04:18 <JoelC> rakhmerov, thanks.
16:04:18 <gokrokve> hi
16:04:47 <rakhmerov> ok, Dmitri. Usually we just walk over agenda items and discuss them
16:04:58 <dzimine> sure
16:05:06 <rakhmerov> the first one is previous action items
16:05:25 <rakhmerov> so
16:05:33 <rakhmerov> #topic Action Items
16:05:36 <rakhmerov> write a simple demo web application that should be deployed on an instance that Mistral will run
16:06:17 <rakhmerov> the description is not really clear I think
16:07:09 <tnurlygayanov_> so it is in progress - it it a web application, which should "do something" on API calls
16:07:20 <rakhmerov> 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 <rakhmerov> yes, right
16:07:29 <rakhmerov> ok
16:07:53 <rakhmerov> and the second AI was: tnurlygayanov, prepare an image with simple demo web app preinstalled on it
16:08:11 <rakhmerov> which obviously depends on the first one :)
16:08:19 <tnurlygayanov_> yes
16:08:19 <rakhmerov> and hence it's in progress too
16:08:21 <rakhmerov> ok
16:09:12 <rakhmerov> btw, I forgot to point to the agenda itself
16:09:15 <rakhmerov> #info https://wiki.openstack.org/wiki/Meetings/MistralAgenda
16:10:02 <dzimine> 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 <rakhmerov> 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 <dzimine> and folks apologize in advance for asking many 101 questions while ramping up.
16:10:45 <rakhmerov> dzimine, unfortunately this page is outdated
16:11:09 <rakhmerov> it's ok, don't hesitate to ask
16:11:53 <rakhmerov> so the best way to look at DSL now is to go to https://etherpad.openstack.org/p/mistral-poc
16:12:26 <rakhmerov> There is a section called "Complete DSL example"
16:12:41 <rakhmerov> so we can use it as a starting point for the discussion
16:13:58 <rakhmerov> dzimine, I know you had some questions and suggestions on how to modify it
16:14:52 <rakhmerov> would please share your ideas?
16:15:06 <dzimine> there are 3 levels of questions
16:15:14 <rakhmerov> I'd suggest we concentrate on main features rather than syntax for now
16:15:41 <rakhmerov> because we should agree on what Mistral should have in terms of functionality first of all
16:15:49 <dzimine> 1) overall structure - the open question there is do we want to mix triggers and workflows together
16:16:27 <dzimine> 2) the key capabilities of workflow, how it reflects in DSL
16:16:43 <dzimine> 3) syntax (and as rakhmerov said it's less important)
16:17:06 <rakhmerov> ok
16:17:35 <dzimine> 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 <dzimine> But you might have agreed on that already, is there a reference?
16:17:57 <stanlagun> 1) This depends on what do you mean by mixing
16:18:16 <rakhmerov> dzimine, what reference do you mean?
16:19:08 <dzimine> 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 <rakhmerov> ooh
16:19:59 <dzimine> 1) I mean, the same definition file contains workbook and event(s) on which it gets triggered.
16:20:46 <dzimine> there may be many events which can trigger the same flow. Including manual
16:20:46 <rakhmerov> 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 <rakhmerov> yes, I got it
16:20:57 <rakhmerov> let's discuss that
16:22:09 <rakhmerov> 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 <rakhmerov> ok, what would be your comments here?
16:22:12 <stanlagun> 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 <stanlagun> side note - it might be a good idea to schedule a voice meeting
16:23:32 <rakhmerov> you would prefer to keep events and workflow separately? And if yes, can you please explain why
16:23:33 <dzimine> IMO we can take 1) mixing events and workflows in the same definition into email discussion
16:23:33 <dzimine> but shortly, the reason is reuse:
16:24:52 <dzimine> to enable creating worklfows that can be triggered by multiple events, some unknown in design time.
16:24:53 <dzimine> a workflow can be triggered by cron, ceilometer, manually, or by another flow
16:24:53 <rakhmerov> yes
16:24:54 <rakhmerov> currently, even if we have some events configured in a workbook we can still reuse it
16:24:54 <dzimine> 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 <rakhmerov> we can always start a workflow via REST API call
16:26:00 <dzimine> 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 <stanlagun> dzimine: you can have several triggers for the same workflow without repeating workflow twice
16:27:58 <dzimine> it can convey a false impression that the flow is triggered by the only events that are described in event section.
16:27:58 <rakhmerov> ok, what would be your suggestion here?
16:27:58 <dzimine> than, if we want to update the triggering condition, we modify the workflow, even though the actual workflow is not modified.
16:28:18 <dzimine> I think of introduce an event-workflow mapping, and REST API that manifests it.
16:28:19 <rakhmerov> stanlagun, yes, I think we need it
16:28:53 <dzimine> let's for now just capture this point of events as part of workflow definition as a discussion point
16:29:41 <rakhmerov> ok, sure
16:34:46 <rakhmerov> I think it's an interesting topic, I believe there's much more to discuss on that
16:35:42 <rakhmerov> #action Discuss separation of events(triggers) and workflow definition in the mailing list and other channels
16:35:42 <dzimine> 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 <stanlagun> ok
16:42:34 <rakhmerov> ok
16:42:34 <rakhmerov> what about key capabilities?
16:42:34 <rakhmerov> it was #2
16:46:16 <dzimine> 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 <rakhmerov> no, not only this
16:46:16 <rakhmerov> we also see use cases for both capabilities
16:46:16 <rakhmerov> unfortunately, we don't have much time to describe all of them right now
16:46:16 <rakhmerov> but we can take it offline
16:46:16 <dzimine> what is the use case for option #2 which is not covered by #1?
16:46:16 <dzimine> ok, we can take it off line
16:46:16 <rakhmerov> so, do you have any suggestions on DSL capabilities?
16:46:16 <rakhmerov> maybe you could describe some key things that you would like to see in DSL
16:46:17 <rakhmerov> so that at least we could capture them
16:46:17 <dzimine> 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 <rakhmerov> so how would it affect the current DSL design?
16:52:53 <dzimine> the 3 options out there show different semantic approaches to doing it.
16:52:54 <rakhmerov> you mean we should rather concentrate on data?
16:52:54 <rakhmerov> because you said "links inputs to outputs"
16:52:54 <rakhmerov> 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 <dzimine> 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 <dzimine> With this:
16:52:54 <dzimine> we will need some expression for workflow primitives, depending on engine capabilities.
16:52:54 <dzimine> E.g., conditions.
16:52:54 <dzimine> or repeats/loops
16:52:54 <rakhmerov> ok
16:52:54 <dzimine> once we agree what the engine must support at the minimum (I say, conditions and loops)
16:53:43 <dzimine> we can talk about how to express them in DSL.
16:53:43 <rakhmerov> ok
16:53:43 <dzimine> 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 <rakhmerov> I just thought DSL would exactly reflect what engine should do :) So it's kind of opposite approach here
16:53:43 <dzimine> oh, sorry, I mean exactly the same. DSL reflects engine's capabilities.
16:53:43 <rakhmerov> yes
16:53:43 <dzimine> it's just how exactly it expresses them? and the same simple capabiltiy - say condition, can be expressed differently in DSL.
16:53:43 <rakhmerov> so I was thinking it's ok that we're discussing DSL instead of what engine should do
16:53:43 <rakhmerov> ok
16:53:43 <rakhmerov> so probably we need to take it offline also
16:53:43 <rakhmerov> #action Discuss key DSL capabilities in mailing list and other channels
16:53:44 <dzimine> 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 <dzimine> and may be joins (point to discuss)
16:53:44 <rakhmerov> yes
16:53:44 <dzimine> so engine capabilities are all agreed, right? something to add?
16:53:44 <rakhmerov> guys, what if we schedule hangouts for tomorrow 8 PST (16.00 UTC) ?
16:53:44 <dzimine> 8:30?
16:53:44 <rakhmerov> because I feel that we have a lot of things to discuss
16:53:44 <rakhmerov> 8.30 would be find to me too
16:54:36 <dzimine> 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 <rakhmerov> dzimine, it's totally fine
16:54:36 <rakhmerov> I mean, believe me we'll have tons of arguments and IMHO it's a normal thing :)
16:54:37 <rakhmerov> 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 <rakhmerov> #action Discuss DSL syntax
16:56:10 <rakhmerov> ok, I'll schedule hangouts
16:57:03 <dzimine> "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 <dzimine> please add as an action
16:57:35 <rakhmerov> ok
16:57:35 <rakhmerov> #action Describe use cases for option 1 and option 2 in https://etherpad.openstack.org/p/mistral-poc
16:58:08 <rakhmerov> ok, we're about to finish
16:59:10 <rakhmerov> I would like we to agree on DSL as soon as possible
16:59:10 <rakhmerov> ideally this week
16:59:17 <rakhmerov> I personally think we don't have too many things on which we disagree
16:59:38 <rakhmerov> it's rather a terminology and other stuff like that
16:59:42 <rakhmerov> see you tomorrow on hangouts
16:59:42 <rakhmerov> #endmeeting