20:00:10 <harlowja> #startmeeting state-management
20:00:10 <openstack> Meeting started Thu Aug 15 20:00:10 2013 UTC and is due to finish in 60 minutes.  The chair is harlowja. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:13 <openstack> The meeting name has been set to 'state_management'
20:00:22 <harlowja> welcome welcome welcome
20:00:45 <harlowja> #link https://wiki.openstack.org/wiki/Meetings#State_management_team_meeting
20:01:09 <kebray> Hello
20:01:16 <harlowja> howday
20:01:45 <changbl> hi
20:01:55 <harlowja> hi
20:02:35 <jlucci> here - btw
20:02:37 <harlowja> hey
20:02:43 <harlowja> thx thx :)
20:03:03 <harlowja> so i think there isn't much status things to report since last time but lets see
20:03:06 <harlowja> #topic status
20:03:14 <harlowja> whats everyone doing????
20:03:37 * harlowja been reworking some of kevins persistence code
20:04:00 <harlowja> and helping make sure the cinder crowd understands the taskflow code there
20:04:07 <harlowja> *answering questions and such*
20:04:14 <harlowja> *or bugs that i might of caused, not to many so far
20:04:19 * kebray evangelizing TaskFlow with other developers at Rackspace.   This will make jlucci happy:  but, found out another internal team wants to move to TaskFlow, specifically _because_ of celery backed distributed state!
20:04:33 <jlucci> That's awesome!
20:04:44 <harlowja> woot !
20:04:47 <jlucci> Can I ask what team? Or is that internal stuffs?
20:06:24 <harlowja> kebray thx for helping evalgelize, i think its not always the most fun activity :)
20:06:50 <kebray> a managed cloud team… they want to move to Heat to replace something internal.  But, they have larger Task Orchestration (which will need to be baked around Heat).  They switched their current solution to celery because it was the only thing they could find that solved their specific scale challenges.
20:07:09 <kebray> anyway… we can take the details offline.
20:07:17 <harlowja> interestingggg
20:07:19 <jlucci> Still awesome. (:
20:07:19 <harlowja> :)
20:08:08 <jlucci> So, I've been working on fixing up some distributed pep8 related stuff
20:08:12 <kebray> harlowja:  I've given a tech talk at 3 of our 5 software development offices in the past two months, and each talk I evangelized both Heat and TaskFlow.  About 125 product folks at Rackspace in total were in attendance across the 3 talks.
20:08:20 <harlowja> kebray wow
20:08:22 <harlowja> cool
20:08:29 <harlowja> jlucci mr.jenkins will be very happy with u
20:08:51 <jlucci> Yeah - still have to fix a couple import things, but that should be done today
20:08:57 <jlucci> Mostly been working on trove related stuff though
20:09:04 <jlucci> Spinning up a _working_ openstack environment
20:09:13 <harlowja> cool
20:09:15 <jlucci> Running trove test cases, starting to put some taskflow codes in there
20:09:25 <jlucci> etc, etc
20:09:26 <harlowja> ya, its interesting to see how it feels to use it
20:09:45 <kebray> harlowja, is it a good thing I hope?  :-/
20:09:46 <harlowja> each different project is also at a different place where they coudl use it in different ways
20:10:00 <harlowja> kebray i think its good of course, ha
20:10:13 <harlowja> but we are all slightly biased :-P
20:10:20 <harlowja> *just slightly*
20:11:06 <harlowja> changbl any think u've been looking
20:11:10 <harlowja> *anything
20:11:43 <harlowja> i'm hoping these persistence adjustments will make it easier to connect zookeepr in
20:11:52 <changbl> harlowja, sorry I did not do much, quite a hectic week. My intern is wrapping up his work here. I will try to do more by next meeting
20:11:58 <harlowja> np :)
20:12:12 <harlowja> i know how it goes, ha
20:12:22 <harlowja> i think the one at y! is heading out shortly to
20:13:06 <harlowja> ok, well lets see if we have any topics to talk about for blocks/engines/stuff there
20:13:18 <harlowja> if not i think a writeup is underway by the people working on it
20:13:27 <harlowja> #topic block-engines-flows
20:13:54 <harlowja> so overall i think there is alot of neat work being done here to help streamline the various usage of tasks
20:14:08 <kebray> harlowja that would be good… I had jlucci explain blocks to me… but, I was struggling to understand… it sounded like another arbitrary primitive.
20:14:29 <harlowja> ya, we want to make sure that its not a struggle to understand, that will be key
20:14:41 <harlowja> the more struggle, the harder it will be for others to see it also
20:14:42 <kebray> And, once you start mixing flow types with execution engines, things get odd.
20:14:50 <jlucci> I think if we ended up using blocks, they'd really just be replacing patterns
20:15:11 <harlowja> possibly, and engines would replace the internals of what runs the patterns
20:15:14 <kebray> ah, patterns I meant… things get weird when you start mixing patterns with execution engines.
20:15:26 <jlucci> Oh, yeah. That was another thing -
20:15:34 <harlowja> melnikov yt
20:15:35 <jlucci> I'm 100% in support of separating engines and patterns
20:15:49 <jlucci> But, after thinking stuff over more, I really don't think we should mix patterns and engines
20:15:59 <jlucci> I think a linear engine should only run a linear flow, etc, etc
20:16:12 <melnikov> yes, i am, hi there
20:16:21 <kebray> If the user doesn't have a reasonable assurance that a pattern will execute in particular way, then the pattern becomes meaningless other than it's a way to hook things up.
20:16:42 <jlucci> Right, it seems that if we allow distributed to run on linear, or something similar, we negate the need for patterns at all
20:16:54 <jlucci> The only thing that remains relevant are the relations
20:16:58 <melnikov> jlucci, have you seen http://paste.openstack.org/show/44004/?
20:16:59 <jlucci> relations between tasks *
20:17:22 <harlowja> i think melnikov  example there would have seperate engines
20:17:42 <melnikov> yes, but thay both run linear flow linearly
20:17:57 <melnikov> and parallel flows in parallel
20:17:59 <melnikov> and so on
20:18:37 <kebray> separate engines or not, I think one needs a reasonable assurance that a pattern will execute in a particular way.. otherwise what jlucci said is right, all that matters is relations and patterns/blocks become irrelevant.
20:18:59 <jlucci> On the flip side as well, if an engine can run any pattern, why make more than one engine?
20:19:06 <jlucci> Why not have only one engine run all the patterns
20:19:12 <kebray> So, both he linear engine and the distributed engine could execute a linear flow… but, they both should execute it linearly!!
20:19:13 <jlucci> *in regards to 44004*
20:19:28 <melnikov> we may have single-threaded, or multi-threaded, or distributed engines
20:19:39 <harlowja> kebray i think thats a must, those kind of guarantees we can't ever break
20:19:41 <melnikov> and choose which is suited best for particular setup
20:19:54 <kebray> good point jlucci… only reason to have more engines is one could be easier to setup, but not scale as well… another could require a lot more configuration and setup, but run at service provider scale.
20:20:15 * harlowja this engine stuff is really neat, ha
20:20:38 <jlucci> Yeah, there's a ton of possibilities with it - just want to make sure we pick the least complicated one. heh
20:20:41 <kebray> so, more than one engine doesn't bother me, as long as the TaskFlow user can reasonably expect a pattern to execute in a way that matches that pattern.
20:21:20 <melnikov> yes, all engines should provide some common high-level guarantees
20:21:27 <melnikov> like, that linear flow is linear
20:21:45 <kebray> Some patterns have execution benefits over other patterns depending on the flow you want.
20:22:03 <kebray> +1 melnikov
20:22:10 <harlowja> agreed, although i also think that jlucci is right, it will be neat to see how the balance works out
20:22:59 <kebray> anyway, write up on blocks would be good… I'm struggling to see where it fits into all this about patterns and engines.
20:23:05 <harlowja> kebray another thing that i think would be useful, maybe if we can get zane b. involved in some of these ideas that would be pretty benefical
20:23:25 <harlowja> even as just a person that offers some experience from heat
20:23:41 <kebray> agreed harlowja.  Maybe you can convince him to participate in TaskFlow at the summit!   It doesn't look like I'm going to be able to go :-(
20:23:46 <harlowja> whatttt
20:23:49 <harlowja> :(
20:24:03 <harlowja> do u want me to register that i'm taking a baby with me
20:24:06 <harlowja> and u can be da baby
20:24:10 <jlucci> lololol
20:24:12 <jlucci> Do that
20:24:15 <jlucci> I want that to happen
20:24:19 <harlowja> lol
20:24:32 <hemna> heh
20:24:34 <kebray> oh my.. not where I expected the conversation to go.
20:25:27 <hemna> get a room
20:25:28 * kebray asks, so where were we on the agenda?
20:25:28 <harlowja> lol
20:25:34 <hemna> :P
20:25:38 <changbl> :)
20:25:42 <harlowja> so melnikov  i think just some writing up would really help
20:25:42 <harlowja> which i think u are doing anyway
20:25:48 <jlucci> lol
20:26:01 <harlowja> i'll see if maybe i can ask zane to look at it and see what he thinks
20:26:14 <harlowja> be nice to have said input, since heat has similar components
20:26:36 <kebray> agreed.
20:27:06 <harlowja> #action melnikov  send out some docs to email list, or IRC, or both
20:27:22 <harlowja> even rough ideas are fine, the engine/blocks/subflows all that are still a WIP i know :)
20:27:56 <melnikov> harlowja, yes, i was hoping to get something written by the meeting, but did not have enough time
20:28:00 <harlowja> np
20:28:18 <harlowja> thx melnikov
20:29:01 <harlowja> cool, so lets continue that discussion and see what happens
20:29:24 <harlowja> next up any cinder/heat/nova/trove/... topics/discussion
20:29:32 <harlowja> #topic integration
20:29:53 <jlucci> Trove stuff is looking pretty promising
20:30:07 <kebray> Cinder integration for H release is done-done, except answering questions and any bug fixes, correct?   That is SUPER cool btw.
20:30:10 <harlowja> so thanks to hemna and jgriffith it has been realitively painless, only a few whitespace issues i caused and maybe a little more
20:30:18 <harlowja> done-done, never done-done
20:30:20 <hemna> :)
20:30:21 <harlowja> always more to do, ha
20:30:29 <hemna> it's never 'done'
20:30:45 <harlowja> its a continuation of space and time
20:30:55 <harlowja> ha
20:31:10 <harlowja> its a start really, i'm gonna help split up the file that i created into pieces, that will help
20:31:30 <harlowja> and continue questions, bug fixes, what the heck is this questions
20:31:45 <harlowja> and as taskflow gets more features, they should be easily added in
20:31:55 <hemna> so what's next for taskflow + cinder?
20:31:56 <harlowja> and world peace at the end
20:32:09 <hemna> taskflow shipped...next up, world peace!
20:32:14 <harlowja> ha
20:32:39 <harlowja> so hemna i'm gonna spend a little time to split up that file with all the tasks, that is part of the plan for me soon
20:32:51 <harlowja> then i think anastsia might be working on another flow there
20:32:55 <hemna> ok
20:33:13 <hemna> there was the debug wrapper thing as well, which could be helpful as a general purpose thing
20:33:19 <harlowja> yup
20:33:33 <harlowja> that exposes the functionality to do persistence, or event recording, or ...
20:33:38 <harlowja> *or its one of the ways to expose it
20:34:17 <harlowja> especially if u imagine all of cinder using taskflow, then the debug thing becomes pretty awesome
20:34:20 <kebray> harlowja can you comment on TaskFlow in Nova?   Is that a "Start evangelizing at the summit" thing and hope a blueprint gets accepted for I release?
20:34:58 <harlowja> kebray hmmmm, i think there will be something going on there, either me, possibly NTT, possibly others, still underflux
20:35:09 <harlowja> i hope to re-enter that area and see what happens
20:35:24 <kebray> Trove isn't core… so, what's our next core target for integration?
20:35:35 <hemna> soren, should we in cinder start to try to implement other capabilities w/ taskflow ?
20:35:42 <hemna> err s/soren/so
20:36:17 <harlowja> hemna i think that would be great, of course, but depends on timing/workflows of everyone i think
20:36:34 <kebray> henna The more use of Taskflow the better.. but, as harlowja says, we're biased :-)
20:36:36 <harlowja> kebray i think it will be nova, glance did mention that they might have a feature there also
20:36:41 <hemna> so we just have volume/clone create today right ?
20:37:11 <harlowja> right, the main create functionality
20:37:21 <hemna> maybe we should create a wiki or something that describes what's left to convert to taskflow
20:37:22 <hemna> for cinder
20:37:27 <harlowja> agreed
20:37:32 <hemna> just want to have it documented
20:37:36 <harlowja> sure
20:37:43 <kebray> I'm also prodding jlucci after trove integration to work on a PoC for Heat.
20:37:46 <hemna> then we can see if we can get folks to pick up the remaining for I
20:38:00 <harlowja> hemna soudns good, let me start one
20:38:07 <hemna> I'd like to see all the main cinder capabilities moved to taskflow, or at least as much as we can in I
20:38:10 <hemna> ok
20:38:11 <harlowja> #action harlowja start cinder flow wiki
20:38:34 <harlowja> all of cinder capabilities??
20:38:35 <harlowja> wow
20:38:36 <harlowja> :)
20:39:03 <harlowja> how far do u want to go is a good question :)
20:39:26 <harlowja> if u look at the distributed work from jlucci it starts to become the thing that could power cinder
20:39:55 <harlowja> then cinder would no longer have an RPC system, but this is likely extremly ambitious
20:40:05 <hemna> well the end game for me is to get
20:40:07 <hemna> cinder into a safe restart capability
20:40:21 <hemna> so that if someone tells cinder to shutdown, or it dies
20:40:28 <hemna> that we can get cinder to pick up where it left off
20:40:30 <hemna> if possible
20:40:40 <hemna> IMHO that's the wholy grail for taskflow
20:40:42 <harlowja> sure, so thats a good goal to, and one that we are aiming for also
20:40:51 <jlucci> heeh
20:41:08 <jlucci> I feel like this is the point where I jump up and start preaching distributed
20:41:11 <harlowja> lol
20:41:20 <hemna> hush
20:41:21 <hemna> :P
20:41:24 <jlucci> :P
20:41:42 <harlowja> haha, so i think hemna your case will def be there pretty soon i think
20:41:48 <kebray> jlucci, you're gonna get a following yet.. I just know it.
20:42:14 <hemna> distributed HA would be nice
20:42:22 <hemna> and taskflow helps us get there I believe
20:42:33 <jlucci> Yeah, as of now, distributed provides the "fix this thing and let the workflow continue on" issue, but is still lacking in the "my box caught fire and I need to resume my flow" issue
20:42:44 <hemna> yah
20:42:56 <hemna> taskflow is a good start to that
20:43:07 <hemna> at least we'll know where in the process the box caught fire :)
20:43:41 <harlowja> ya, there is an interesting area that jlucci i think is uncovering really, if u look at all the openstack projects, they execute tasks via some code, using this RPC thing, then if u look at jlucci distributed stuff and taskflow integration u start to see the same thing
20:43:43 <jlucci> Yes. lol We're trying to get all the persistence stuff in right now - harlowja is doing some fixes on that
20:44:45 <hemna> some use cases are going to be difficult to reconcile moving to other machines though
20:44:53 <hemna> in the case of cinder's copy volume to image
20:45:01 <hemna> the cinder node mounts the backend volume
20:45:04 <hemna> and starts the copy
20:45:14 <harlowja> sure, i'm pretty sure jlucci has a solution there, haha, like celery has to have it i wuld think
20:45:16 <hemna> that mounting would have to be reissued on the next box if the primary burned
20:45:50 <hemna> in this case the process would need to be started over from the beginning I thinks
20:46:10 <jlucci> And that's something taskflow will be able to provide
20:46:18 <harlowja> or from the last checkpoint, which is something we've been figuring out how to semantically support (And actually do)
20:46:27 <jlucci> I want to see the option of giving the user a "flow failed action"
20:46:33 <hemna> ah yah, checkpointing.  nice
20:46:37 <hemna> yah that'd help for sure
20:46:54 <harlowja> ya, melnikov i think has been thinking about this more than me recently, but def its wanted
20:47:12 <hemna> completely awesome
20:47:24 <harlowja> thx hemna  :)
20:48:39 <harlowja> alright, just gonna open it up for anything else to discuss since it seems like we are done for now talking about how integration is going
20:48:44 <harlowja> #topic open-discuss
20:49:41 <harlowja> any interesting question, that i think we never quite finished is the question releated to persistence
20:49:57 <harlowja> and might still be an open question until its a little more flushed out
20:50:10 <harlowja> we have some basic concept/idea of what to store, which is great, ha
20:50:44 <harlowja> my question though is if there should be a limit to how long we store it
20:51:02 <jlucci> When I first started taskflow stuffs, I had an idea that we sort of "purged as we went along"
20:51:11 <melnikov> i think checkpoints might provide good answer
20:51:16 <jlucci> I'm not sure if it's feasible, but the idea is that once you get to a checkpoint,
20:51:26 <jlucci> you can sort of consolidate the data up to that point
20:51:37 <jlucci> You don't have to keep track of the states of any previous taks or anything like that
20:51:53 <harlowja> seems reasonable
20:52:15 <jlucci> I just worry that someone's gotten to a checkpoint, and wants to roll back to a previous one
20:52:22 <jlucci> We have to make sure we store enough data to make that possible
20:52:25 <jlucci> But nothing more
20:52:39 <jlucci> Might be something we solve when we actually start implementing checkpoints though
20:53:52 <harlowja> sure, i could see there be an interesting case for checkpoints, for taskflow internal usage
20:54:19 <harlowja> and still providing the abilitiy to attach lisenters to a flow so that say cinder can log all the things happening (or store it in there own little api)
20:55:15 <harlowja> seems like there is internal storage, which involves checkpoints and state/task/flow information, and then letting say cinder see what is happening in taskflow, and then say cinder can store that and tell people about whats happening if they want
20:55:23 <harlowja> make sense?
20:56:12 <harlowja> if not thats ok, just brainstorming, ha
20:56:33 <jlucci> I think so
20:56:51 <jlucci> This is in line with the restricting what can be accessed from the DB type stuff we talked about yesterday?
20:57:37 <harlowja> hmmmm, possibly
20:57:39 * harlowja can't remember, ha
20:58:00 <harlowja> anyways, we can continue later in #openstack-state-management
20:58:01 <harlowja> all are welcome to bug us :)
20:58:13 <jlucci> Sounds good
20:58:19 <jlucci> :D
20:58:21 <harlowja> thx again everyone :)
20:58:28 <harlowja> #endmeeting