16:00:22 <rakhmerov> #startmeeting Mistral
16:00:23 <openstack> Meeting started Mon Aug 18 16:00:22 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:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:26 <openstack> The meeting name has been set to 'mistral'
16:00:38 <dzimine> yahoo!
16:00:45 <rakhmerov> hey :)
16:00:52 <NikolayM> hi !
16:01:06 <rakhmerov> as usually, let's wait one more minute
16:01:25 <rakhmerov> in the meantime I'll remind the agenda
16:01:50 <rakhmerov> 1. Review action items
16:01:50 <rakhmerov> 2. Current status (progress, issues, roadblocks)
16:01:50 <rakhmerov> 3. Further plans
16:01:52 <rakhmerov> 4. Release 0.1 scope (BPs and bugs)
16:01:54 <rakhmerov> 5. Open discussion
16:01:54 <akuznetsova> Hi
16:01:59 <rakhmerov> hi )
16:02:22 <rakhmerov> #topic Review Action Items
16:02:32 <rakhmerov> we didn't have any action items last time
16:02:36 <rakhmerov> done
16:02:54 <dzimine> last time was fast and easy :)
16:03:07 <rakhmerov> #topic Current Status
16:03:14 <rakhmerov> yeah )
16:03:23 <rakhmerov> it was my favourite meeting ever )
16:04:26 <akuznetsova> last week I worked on mistral-workflow-execution-tests blueprint
16:05:25 <rakhmerov> my status: 1) finished several important things including reverse workflow, data flow integration, linear workflow and a bunch of fixes in specifications and DB models, now I am working on putting all things together: end-to-end testing of more complex workflow with cross-workflow calls
16:05:45 <rakhmerov> akuznetsova, ok, cool
16:06:26 <rakhmerov> one more important thing we did: we played 'planning poker' with Nikolay and estimated the time scope for all the BPs now scheduled for 0.1 released
16:06:32 <dzimine> #info: dzimine  - we reviewed and agreed on 0.1 scope. Other - reviews. No code contrib on my side. This week - looking into DSL and design for handling multiple data values. Got an idea, target to share it by tonight.
16:06:53 <rakhmerov> ok, very cool
16:06:58 <NikolayM> I worked on openstack-actions blueprint, also did some integration tests
16:07:12 <rakhmerov> yep, cool
16:07:13 <NikolayM> ooh, yes
16:07:28 <NikolayM> we planned all blueprints with Renat
16:07:32 <rakhmerov> NikolayM, were you able to fix your integration tests today?
16:07:36 <dzimine> NikolayM: the openstack tasks are cool indeed.
16:07:48 <rakhmerov> I didn't have time to look at them in the evening
16:08:09 <rakhmerov> yes, great work, Nikolay!
16:08:14 <NikolayM> yes, I've already fixed it
16:08:17 <rakhmerov> ok
16:08:34 <rakhmerov> #topic Further Plans
16:08:48 <dzimine> I meant to ask: how do you generate the .json of the actions?
16:08:49 <rakhmerov> I guess we've mostly already told about our further plans
16:08:58 <akuznetsova> rakhmerov, I looked through our workflows in resources folder and covered the most appropriate, so we need to discuss which scenarios should be covered more
16:09:27 <rakhmerov> akuznetsova, ok, let's skype tomorrow and talk about it
16:09:40 <akuznetsova> rakhmerov, ok
16:10:03 <dzimine> @rakhmerov: I think we need a second workflow handler to see two at play. It doesn’t have to be a big and real, a fake handler which knows to only handle one task might do.
16:10:05 <rakhmerov> #action rakhmerov, skype on Tue with Nastya about integration testing scenarious
16:10:43 <rakhmerov> dzimine, fake handler is a cool idea actually
16:11:02 <rakhmerov> although I already implemented both linear and reverse
16:11:15 <dzimine> oh you implemented linear, sorry I am behind on reviews.
16:11:18 <rakhmerov> I committed linear today
16:11:22 <rakhmerov> :)) np
16:11:26 <dzimine> linear, or direct?
16:11:35 <dzimine> I’ll take a look never mind.
16:11:45 <rakhmerov> I called it linear for now even though I don't fully like this name
16:12:04 <rakhmerov> because strictly speaking it's not linear, it can also be parallel if needed
16:12:15 <rakhmerov> but just didn't come up with a better term so far
16:12:23 <rakhmerov> we can change it any time
16:12:32 <rakhmerov> so I'm open to any suggestions
16:12:47 <dzimine> “direct”
16:13:12 <dzimine> the proper name is “arbitrary directed graph”
16:13:33 <dzimine> and we save “linear” for “sequentual linear”, and can also implement “strictly parallel".
16:14:17 <dzimine> or cross out “linear” all together: at the end we have “reverse”, “sequential”, “direct”, and “parallel".
16:14:31 <rakhmerov> the only thing I haven't fully implemented so far is stopping and resuming, it's not too important right now, deferred it for a little bit
16:14:31 <rakhmerov> yeah, may be
16:14:32 <rakhmerov> for some reason I don't really like "direct" too
16:14:32 <rakhmerov> even though it's more consistent I think with "reverse", right?
16:15:31 <rakhmerov> not sure I understand
16:15:56 <rakhmerov> what's the diff between "sequential", "direct" and "parallel"?
16:16:17 <akuznetsova> Am I right, that reverse workflow can be “sequential” and "parallel" ?
16:16:33 <rakhmerov> I think we don't need to implement truly linear workflow, it's just a subset of what might be called "parallel"
16:16:48 <rakhmerov> akuznetsova, mmmm... not really
16:17:09 <rakhmerov> reverse workflow (as we call it now) is a workflow based on task dependencies only
16:17:36 <rakhmerov> pretty much like make files look like, or ant (if you're familiar with Java)
16:17:55 <akuznetsova> so, what is "direct/linear" workflow?
16:18:39 <dzimine> different types of workflows make different trade-offs. They may have similar properties, but they may be expresssed differently
16:18:45 <rakhmerov> "direct/linear" is when taskA completes and after that we decide what next tasks should run based on certain conditions
16:19:13 <rakhmerov> dzimine, true
16:19:19 <dzimine> direct workflow is when user explicitly defines the sequence, starting from the first task, and on, with keywords like “on-success”, on-failure, on-completion.
16:19:34 <rakhmerov> yes
16:19:51 <dzimine> direct workflow IMPLIES that many tasks can be executed in parallel, if dependencies are resolved.
16:20:02 <rakhmerov> right
16:20:21 <dzimine> It’s powerful and convinient but may turn out pretty complex once many forks happen.
16:20:36 <rakhmerov> so your suggestion would be to rename what I named "linear" to "direct", right?
16:20:36 <akuznetsova> dzimine, rakhmerov  thanks
16:20:45 <rakhmerov> np
16:21:12 <rakhmerov> ooh, trade-offs
16:21:20 <rakhmerov> I think I see now what you mean
16:21:50 <dzimine> ‘sequential’ workflow - IMO we’ll need it to offer simple straightforward syntax - it’s the flow which executes tasks in strict sequence, one at a time. Pros: siimpler syntax, transparency - look at file, tasks executed in the order of appearance in the file. For 80% of automation tasks it will be enough :)
16:22:36 <rakhmerov> so you mean that in some scenarios we may want to switch off 'parallelism' at all to gain some performance improvement
16:23:09 <rakhmerov> ok
16:23:22 <rakhmerov> I see now
16:23:43 <rakhmerov> then I think we need to rename "linear" to "direct" now
16:24:04 <rakhmerov> and then decide what other explicit workflow types we need
16:24:48 <rakhmerov> #action rakhmerov, rename the current "linear" workflow type to "direct" and discuss with the team what other workflow types may be needed
16:25:03 <dzimine> It will be a killer when it comes to calling workflows from workflows.
16:25:41 <dzimine> And once we are talking “renames”, I please ask you all to consider renaming “finish”->”complete” across the whole project.
16:26:19 <rakhmerov> "finish"->"complete"?
16:26:27 <rakhmerov> you mean "on-finish"?
16:27:06 <akuznetsova> what is the point ?
16:27:23 <rakhmerov> just better english, in fact
16:27:44 <dzimine> http://www.jumbojoke.com/whats_the_difference_between_complete_and_finished.html
16:28:02 <dzimine> "Some say there is no difference between complete and finished. Please explain the difference between complete and finished in a way that is easy to understand."
16:28:03 <dzimine> His astute answer: "When you marry the right woman, you are complete. But, when you marry the wrong woman, you are finished. If the right one catches you with the wrong one, you are completely finished."
16:28:48 <rakhmerov> yeah-yeah, that's really cool :))
16:29:08 <rakhmerov> I don't Mistral to be finished :))
16:29:12 <rakhmerov> haha
16:29:18 <rakhmerov> I want it to be complete )
16:29:22 <NikolayM> :) )))
16:29:39 <NikolayM> indeed
16:30:01 <dzimine> complete is 1) more common in similar cases and 2) it’s both adj and verb, thus we can have STATUS=COMPLETE (not FINISed), on-complete (not on-finished) 3) finish is a noun and verb, and we never use “noun” form of it.
16:30:07 <dzimine> Anyways, I am just picky :)
16:30:28 <rakhmerov> #action rakhmerov, nmakhotkin: when doing renamings make sure to rename "finish" to "complete (http://www.jumbojoke.com/whats_the_difference_between_complete_and_finished.html)
16:31:13 <rakhmerov> that's fine
16:31:40 <rakhmerov> I insist that you continue to be picky :)
16:32:02 <rakhmerov> alright
16:32:21 <rakhmerov> #topic Release 0.1 scope (BPs and bugs)
16:32:58 <rakhmerov> even though we pretty much agreed on the scope I decided to include it into today's agenda to have a chance to make some corrections if we need to
16:33:52 <rakhmerov> this is the link: https://launchpad.net/mistral/+milestone/0.1
16:33:58 <dzimine> ok, let’s glance over and see.
16:34:21 <rakhmerov> so I suggest that we look at it now one more time
16:34:22 <rakhmerov> yep
16:35:06 <dzimine> LGTM
16:35:54 <rakhmerov> as I said before we estimated these BPs with Nikolay and here is the more detailed estimation with task breakdown: https://docs.google.com/a/mirantis.com/document/d/1jw-yqGSuBsWz23ZInWLMQBbBH4IA9UXjPPt5qlkkobo/edit#heading=h.ni0jo8o0h1ae
16:36:17 <rakhmerov> dzimine, ok
16:36:36 <rakhmerov> as you suggested I removed "join" from 0.1
16:37:10 <rakhmerov> the main goal is to finish all the main capabilities and polish the new architecture
16:38:44 <rakhmerov> one specific question that I have is "we definitely won't be able to include all desired V2 capabilities into 0.1 release. So what do we do next? Just announce it's only a part of v2 or say 0.2 release will include API v3?"
16:38:51 <rakhmerov> the last option is kind of scary to me )
16:39:47 <dzimine> the delayed-messagin is the only thing I don’t agree on high prio.
16:39:49 <dzimine> https://blueprints.launchpad.net/mistral/+spec/mistral-delayed-messaging
16:39:53 <rakhmerov> I think the most reasonable way is to design it so that all additions would for a superset of what we'll deliver in 0.1
16:40:22 <dzimine> May be you can see it better from the new implementation’s standpoint.
16:40:37 <rakhmerov> dzimine, Nikolay already started wokring on it
16:41:05 <rakhmerov> it shouldn't be too hard even though oslo.messaging is not the best friend in this :)
16:41:26 <rakhmerov> dzimine, maybe you're right
16:41:46 <dzimine> Just announce it's only a part of v2 to me sounds better than 0.2 will have v3 API
16:41:50 <rakhmerov> I'm just thinking about how we're going to announce 0.1 release
16:41:59 <rakhmerov> yes, absolutely
16:42:25 <dzimine> The question is do we reach functional parity with the 0.0.2
16:42:31 <dzimine> with the current. If we do, we are good.
16:42:36 <rakhmerov> right, the most important thing is that following changes should be backwards compatible
16:42:55 <dzimine> if we don’t, admit it and say 0.2 will be the point.
16:43:20 <rakhmerov> so what do you mean by "parity" precisely?
16:43:39 <rakhmerov> you mean all those capabilities or backwards compatible API?
16:43:54 <rakhmerov> if API then no, it's impossible
16:44:45 <rakhmerov> as far as capabilities, the only thing I see now is triggers: we didn't really schedule them for 0.1. All the rest should be implemented
16:45:41 <rakhmerov> and we're going to deliver even more actually in 0.1 (e.g. workflows from workflows, multiple workflows, policies etc.)
16:46:52 <dzimine> I mean functional parity, which is everything you can do with 0.02 you can also do with 0.1
16:47:08 <rakhmerov> yes, I think it will be done
16:47:10 <dzimine> So that there is nothing you can not do with 0.1 which is possible in the previous version.
16:47:23 <rakhmerov> yes, except triggers
16:47:27 <dzimine> At this point we can depricate the previous functionality.
16:47:34 <rakhmerov> right
16:47:41 <rakhmerov> I'd love to do that
16:47:49 <dzimine> Triggers don’t bother me - not currently used much.
16:47:57 <rakhmerov> correct
16:48:13 <rakhmerov> btw, there will be some interesting changes in them too
16:48:21 <rakhmerov> but that's for later, maybe for 0.2
16:48:54 <rakhmerov> we at Mirantis find them pretty interesting long-term feature rather
16:49:06 <rakhmerov> ok
16:49:26 <rakhmerov> so, it's decided
16:49:48 <dzimine> folks do we already have a blueprint for multiple task invocations?
16:51:01 <rakhmerov> you mean https://blueprints.launchpad.net/mistral/+spec/mistral-dataflow-collections?
16:51:27 <dzimine> yes thank you.
16:51:35 <rakhmerov> we don't have it scheduled for 0.1
16:52:15 <rakhmerov> is it fine? I excluded it from 0.1 because we didn't really see how it should be design from DSL perspective
16:52:30 <dzimine> no. Just it’s my delivery to have a DSL idea for this.
16:52:30 <rakhmerov> so it seemed to risky within this time frame
16:52:48 <rakhmerov> right
16:53:04 <rakhmerov> I think it's ok, because design of this feature may affect everything else
16:53:23 <rakhmerov> that's why I think we need to come up with ideas asap
16:54:06 <rakhmerov> if we feel comfortable at the and of this cycle we may want to try implementing it, but not really sure
16:54:30 <rakhmerov> only if folks from Stackstorm help us :)
16:55:21 <rakhmerov> ok, anything else?
16:55:40 <rakhmerov> good discussion today
16:55:53 <rakhmerov> 4 mins left
16:56:17 <akuznetsova> not from my side
16:56:22 <rakhmerov> I'm personally out of ammo and ready to shut down the meeting
16:56:46 <NikolayM> bye!
16:56:52 <akuznetsova> bye
16:56:58 <rakhmerov> ok, guys, thanks! Thanks Dmitri!
16:57:03 <rakhmerov> bye
16:57:13 <rakhmerov> #endmeeting