20:00:44 <harlowja> #startmeeting state-management-goodness
20:00:45 <openstack> Meeting started Thu May  9 20:00:44 2013 UTC.  The chair is harlowja. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:48 <openstack> The meeting name has been set to 'state_management_goodness'
20:00:55 <harlowja> howdy everyone!
20:01:21 <changbl> hello~
20:01:22 <harlowja> anyone interesting in state management stuff (previously orchestration) let me know
20:01:29 <harlowja> *rollcount
20:01:36 <harlowja> *role count i mean, ha
20:01:37 <hemna> sup
20:02:08 <harlowja> so today i might have some what of an agenda :)
20:02:19 <adrian_otto> hi
20:02:28 <harlowja> howdy
20:02:30 <esheffield> hello
20:02:50 <harlowja> #link https://wiki.openstack.org/wiki/Meetings/StateManagement#Agenda_for_next_meeting
20:03:36 * alaski lurks
20:03:39 <harlowja> so i was thinking about how to better define what i and others are trying to do, does that seem like it would help others :)
20:03:58 * sandywalsh stalks alaski
20:04:09 <harlowja> since there are many wikis, and not everyone gets the time to read them, so a TLDR might be useful
20:04:45 <harlowja> then we can talk about some of the primitives that i put up, some of the placement of this 'taskflow' library
20:05:09 <harlowja> and discuss on some of the ML topics that were brought up regarding usage, core people support and such
20:05:20 <harlowja> and then anything else people want to talk about
20:05:30 <harlowja> sound good?
20:05:35 <changbl> ok
20:05:43 <harlowja> #topic summary
20:06:06 <harlowja> so the TLDR version that i have sorta been thinking about is….
20:07:28 <harlowja> basically alot of actions that occur in various openstack projects can be simplified into a set of actions on resources (virtual or real) and states of those resources, such things could be called workflows ontop of said resources to fullfill said action
20:07:45 <maoy> hola
20:08:43 <maoy> i thought we liked "taskflow" instead of workflow from last week. :) anyway. keeping going harlowja~
20:09:07 <harlowja> sorry, just giving an overview TLDR of my whole grand vision thingy :-P
20:09:10 <harlowja> thx
20:09:41 <harlowja> due to the evolutionary development process that openstack has gone through there hasn't be a strong focus on this simplification into actions and states, just due to the organic growth of the different openstack core projects, the underlying code is there to do most of the actions and states but the simplification into actions and states hasn't really occured, which is nothing to be ashamed of
20:11:24 <harlowja> so my idear was to move toward said simplification, which is starting to occur for example with nova conductor work, but instead of just moving code around also rethink some of the primitives that are needed to structure these actions and states into a model that when simplified allows for advanced things to occur on said actions and states
20:11:52 <harlowja> taskflow, at least from what i think is the foundation of said work
20:11:58 <harlowja> so thats my TLDR summary, haha
20:12:15 <harlowja> *i hope that made it a little more understandable
20:12:49 <harlowja> maoy and changbl  have done similar work i think in there previous at&t research (which was neat)
20:13:21 <changbl> which project are we gonna start with? Nova, Oslo, or Heat?
20:13:44 <harlowja> so thats a very interesting question
20:13:52 <hemna> Do you have a BP on how you are going to go about simplifying things?
20:14:07 <harlowja> the amount of info doesn't really fit in one BP :)
20:14:18 <hemna> We in Cinder are interested in state management as well and are looking at a "state machine/object" as well
20:14:30 <harlowja> #link https://wiki.openstack.org/wiki/StructuredStateManagement is sorta my entry point into this
20:14:54 <harlowja> hemna i think alot of core projects want this, or at least want to get to something like this
20:14:56 <adrian_otto> I edited that yesterday to add a link to the primitives document in the bottom section
20:15:02 <harlowja> adrian_otto thanks
20:15:11 <adrian_otto> hemna: have you seen that yet?
20:15:15 <hemna> not yet
20:15:19 <hemna> thanks for the link
20:15:26 <adrian_otto> https://wiki.openstack.org/wiki/StructuredWorkflowPrimitives
20:15:41 <adrian_otto> that's a pretty breif description of what gets built first
20:15:43 <harlowja> sure, so placement is a very good question and releates a little bit to adrian_otto and similar conversations on the ML
20:15:48 <maoy> so, from the mailing list discussion, it seems to be prefered to not start from Oslo, then move to Oslo
20:16:06 <adrian_otto> this will definitely end up in Oslo
20:16:21 <adrian_otto> there is no doubt. It's just a matter of when it's at the right maturity level to enter there.
20:16:30 <harlowja> agreed
20:16:43 <maoy> we just need to figure out which non-oslo to begin with
20:16:48 <maoy> heat, cinder, nova?
20:16:52 <jgriffith> cinder :)
20:16:54 <maoy> reddwarf?
20:16:55 <hemna> :)
20:17:02 <harlowja> and i think myself and others want to get it into oslo, but there is still alot of experimentation and work to get it to that stage i think
20:17:08 <maoy> jgriffith: great!
20:17:18 <adrian_otto> RedDwarf can use it probably sooner than Heat will be ready. That's my sense of it.
20:17:22 <jgriffith> maoy: harlowja what about a joint nova/cinder first round
20:17:26 <harlowja> so the question is what can be done to do heat, cinder, nova, reddwarf at once :)
20:17:30 <jgriffith> after that's proven out a bit we push to oslo
20:17:46 <adrian_otto> well, even before that possible
20:17:52 <jgriffith> harlowja: insists on asking hard questions
20:17:57 <harlowja> haha
20:17:59 <adrian_otto> we just need it in one project, and a pull request for a second
20:18:13 <adrian_otto> but let's not put the cart before the horse
20:18:19 <jgriffith> adrian_otto: that's fine but I think we need some up front coordination and collab on the design
20:18:21 <hemna> cinder has a BP for a "state machine/object" for Havana.  https://blueprints.launchpad.net/cinder/+spec/cinder-state-machine
20:18:30 <adrian_otto> I'd like to take a moment to see if the current plan would meet Cinder's needs.
20:18:43 <harlowja> hemna interesting, did not know about that
20:18:59 <harlowja> so a potential plan could be…
20:19:01 <hemna> It's not much, mostly a placeholder for a desired state mgmt for cinder
20:19:41 <jgriffith> adrian_otto: sorry I was late, is there a wiki or some docs on the current plan you referred to?
20:19:55 <harlowja> say we form a group of devs that want to work on this, have active core members of said sub-projects involved (maybe not coding it, but involved) and start said project in stackforge to encourage rapid development on said project
20:19:58 <hemna> jgriffith, https://wiki.openstack.org/wiki/StructuredWorkflowPrimitives
20:20:17 <jgriffith> hemna: thanks
20:20:24 <adrian_otto> is "https://launchpad.net/%7Ewalter-boring" in this chat?
20:20:31 <hemna> <--
20:20:35 <adrian_otto> ok, cool
20:21:06 <changbl> +1 to harlowja
20:21:09 <adrian_otto> and is "https://launchpad.net/%7Ejohn-griffith" also here?
20:21:10 <harlowja> i personally just feel that if we start in stack forge, we can prototype really fast, have active core members from say reddwarf, nova, heat involved in the ideas (maybe not code)
20:21:30 <hemna> harlowja, +1 I'm ok with that.
20:21:36 <harlowja> we could even publish a pypi package of this (when it reaches some level of maturity) that those core projects can use
20:21:41 <adrian_otto> +1
20:21:45 <harlowja> and when its more stabilized shift to oslo
20:21:53 <maoy> harlowja: i'm not sure we need to start from stackforge given cinder's strong demand. why not directly into cinder?
20:22:08 <adrian_otto> using stackforge comes with advantages of the CICD resources form OpenStack
20:22:18 <adrian_otto> s/form/from/
20:22:25 <harlowja> maoy i think other projects also have strong demands for this so its not just 1 strong demand i feel
20:22:54 <maoy> fair enough.
20:23:00 <maoy> so let me get the procedure right:
20:23:02 <jgriffith> just fyi from my perspective I"m fine with either approach but I would likely suck things in to cinder earlier anyway
20:23:14 <harlowja> i agree, sucking in early would be the goal
20:23:41 <adrian_otto> hemna: woudl something implementd in a library that lets you have a local state machine fork for your use case, or are you looking for an API controlled service?
20:23:45 <maoy> commit into stackforge, copy paste into cinder, convert cinder code to using the library?
20:23:54 <harlowja> copy paste
20:23:55 <harlowja> eck
20:24:07 <jgriffith> adrian_otto: lib for state machine is what I had planned for now at least
20:24:16 <jgriffith> hemna: agree?
20:24:19 <adrian_otto> ok, good, that's what we will ahve first
20:24:21 <harlowja> i was thinking that we could directly publish a pypi library no?
20:24:26 <hemna> yah that's fine.
20:24:35 <hemna> don't have strong feelings either way about that
20:24:44 <hemna> an API might be better long term...dunno
20:24:53 <harlowja> copy paste scares me :)
20:25:01 <jgriffith> harlowja: I'm debating that same thing with the idea of brick but I don't know that it's important to weigh in right now (because I can't) :)
20:25:22 <adrian_otto> so it looks like using Cinder's blueprint as the first one would make sense. I'm really happy to have more eyeballs on this.
20:25:24 <harlowja> ya, its new ground
20:25:50 <harlowja> so does everyone think that process would be a good first step?
20:25:58 <adrian_otto> RedDwarrf and Heat should be close after.
20:26:32 <hemna> hopefully before H3 we could get this in oslo though
20:26:33 <harlowja> stackforge, have interested core members involved in library, work partially toward cinders BP as a potential first target
20:26:47 <adrian_otto> Nova may end up being later, but we can start small there, and iterate toward the more demanding task flows
20:26:59 <harlowja> adrian_otto agreed
20:27:00 <maoy> sounds like a great plan
20:27:02 <harlowja> hemna agreed to
20:27:15 <changbl> soudns good to me
20:27:15 <jgriffith> wow, folks are in a good mood today :)
20:27:16 <harlowja> maximal code, minimal red tape is my goal :)
20:27:21 <hemna> sweet.
20:27:22 <maoy> although for the record, i do prefer to start from cinder directly..
20:27:33 <maoy> just better focus and easier to debug
20:27:49 <hemna> I'm ok with it living in cinder for now as well.
20:28:09 <harlowja> maoy this is where i think having said core memebers involved in said library comes into play
20:28:11 <jgriffith> I think if we advertise the effort it works fine
20:28:19 <jgriffith> and we get gating and unit testing which is critical
20:28:25 <adrian_otto> awesome, that may actually reduce complexity too
20:29:01 <jgriffith> harlowja: although to be fair I'm not all that familiar with using stackforge
20:29:16 <harlowja> its pretty simple, u get the gating and unittests also
20:29:29 <jgriffith> ahh... yeah, looking at it now
20:29:43 <adrian_otto> let's not bother with StackForge if working in Cinder is preferred
20:29:54 <maoy> harlowja: IMO it's just slightly more painful to have two projects in the beginning.
20:30:07 <adrian_otto> the sooner this makes it to Oslo the better it will be for all the stakeholders
20:30:08 <jgriffith> I prpose we at least try it and if it seems problematic revist the decision
20:30:22 <jgriffith> cinder that is ^^
20:30:25 <changbl> +1 to maoy
20:30:30 <changbl> better 1 project to start
20:30:32 <adrian_otto> +1
20:30:39 <hemna> ok +1 for cinder
20:30:44 <maoy> adrian_otto: good point. if we get attractions in cinder, we might skip stackforge and go directly to olso
20:31:12 <harlowja> ok, so seems like we have some consensus :)
20:31:18 <maoy> if we don't, we can still use stackforge..
20:31:37 <harlowja> #agreed attempt at developing taskflow in cinder to start
20:31:47 <harlowja> sound good?
20:31:51 <adrian_otto> we might use stackforge to kickstart the API service built on the taskflow library's state machine code
20:31:52 <maoy> yeah
20:32:05 <adrian_otto> as that's probably more than Cinder's charter calls for
20:32:31 <harlowja> ya, there is a whole transition to oslo that i'm not sure about
20:32:52 <harlowja> but i guess we can hit that when we get there
20:33:33 <maoy> harlowja: agreed
20:34:21 <harlowja> ok, so thats good news, it would still be useful to me to have interested other core members involved
20:34:29 <harlowja> at least in design i think :)
20:34:45 <jgriffith> harlowja: +1 I think that's a requirement
20:35:07 <harlowja> cool, then it won't become so cinder specific we will be like oops, that might not work so well over there in X project
20:35:18 <jgriffith> yup
20:35:25 <maoy> absolutely
20:35:33 <harlowja> cool
20:35:35 <adrian_otto> hub_cap agreed to be on it
20:35:49 <jgriffith> we can even have lazy rules about +2/A for cinder core folks
20:35:55 <maoy> pardon my ignorance. do we have heat core in the room?
20:36:11 <adrian_otto> shardy: yt?
20:36:20 <harlowja> #agreed have core 'sponsors' from other projects that want to use said taskflow library (starting in cinder) be involved from the start in design (and even code if they have time)
20:37:36 <harlowja> so thats cool, great news to me :)
20:37:58 <harlowja> maybe i can send a ML email to get interested parties (that might not have shown up here)
20:38:03 <harlowja> sound good?
20:38:09 <jgriffith> harlowja: sounds good to me
20:38:14 <changbl> yes
20:38:20 <adrian_otto> maoy: looks like no, heat code (shardy) is not here
20:38:22 <harlowja> #action harlowja send email to ML to get other interested core people involved
20:38:27 <adrian_otto> s/code/core/
20:38:37 <maoy> adrian_otto: ack. np
20:38:54 <anniec> sounds good harlowja, will be good to get a nova core volunteer ;P
20:39:10 <harlowja> of course
20:40:04 <maoy> jgriffith: which API(s) in cinder (or prodedures, workflows, taskflows) do you see has the potentials to be the early adoptor?
20:40:25 <jgriffith> maoy: My primary focus to start is state transistion on the volume life-cycle
20:40:50 <jgriffith> maoy: hemna may have additional input for FC
20:41:34 <jgriffith> maoy: currently like most we just fill in a string at various points in the code
20:41:39 <maoy> jgriffith: does cinder have a state transition graph like this in nova? http://docs.openstack.org/developer/nova/devref/vmstates.html
20:41:49 <maoy> oops. the graph is not rendered.
20:42:01 <harlowja> #link ttp://docs.openstack.org/developer/nova/devref/vmstates.html
20:42:06 <harlowja> #link http://docs.openstack.org/developer/nova/devref/vmstates.html
20:42:26 <harlowja> #topic cinder-primitives
20:42:32 <hemna> I don't think I've seen one
20:42:38 <jgriffith> maoy: harlowja we do not
20:42:42 <jgriffith> so there's the first task :)
20:42:44 <harlowja> :)
20:42:47 <maoy> hehe
20:42:55 <harlowja> ya, that is expected i think, gotta figure out what its doing first ;)
20:43:04 <harlowja> then how to map it to taskflow
20:43:29 <harlowja> and this is where the primitives might come in handy
20:43:35 <harlowja> #link https://wiki.openstack.org/wiki/StructuredWorkflowPrimitives
20:44:07 <jgriffith> k... we'll have to move pretty quick and get some of this put together
20:44:14 <harlowja> *others feel free to add any ones that they think are useful also*
20:44:26 <harlowja> jgriffith agreed, quickness is part of the fun
20:44:31 <jgriffith> :)
20:44:39 <jgriffith> hemna: and I can sort that out
20:44:43 <hemna> ok
20:44:45 <jgriffith> at least the initial pieces
20:44:57 <harlowja> that be very useful, at least then we can sorta discuss as to how it might fit
20:44:57 * jgriffith likes to volunteer hemna for things :)
20:44:59 <harlowja> and adjust from there
20:45:04 <hemna> :P
20:45:16 <harlowja> and debate about any new primitives, or removing other ones and so on
20:46:02 <harlowja> i was sort of forming this for these types of things
20:46:04 <harlowja> #link https://wiki.openstack.org/wiki/StructuredWorkflows
20:46:05 <jgriffith> sounds good... maoy, adrian_otto ?
20:46:22 <harlowja> that could be the multi-project main page for this kind of stuff
20:46:50 <jgriffith> harlowja: sure
20:47:06 <maoy> jgriffith: great. look forward to it
20:47:39 <harlowja> #action jgriffith hemna document a possible taskflow,workflow to take, then reconvine via ML (or email or IRC) about how library (which is slightly in progress) may have to be adjusted to accomdate
20:47:39 <jgriffith> #action cinder team to provide cinder workflow data
20:47:46 <jgriffith> haha!
20:47:48 <harlowja> :)
20:48:11 <hemna> rock on!
20:48:29 <harlowja> it'd be very interesting to start collecting what the other taskflows other core projects think would be useful to 'attack' on there end
20:48:38 <harlowja> since the more knowledge we can gather, then better we can design
20:48:43 <harlowja> *the better
20:49:00 <harlowja> nova is an interesting one that has many potential paths
20:49:42 <harlowja> *and is the one i am most familiar with, although maoy i would think knows best
20:49:50 <harlowja> maoy or russellb or others
20:50:27 <harlowja> but not an immediate need i guess :)
20:50:39 <harlowja> #topic open-dicussion
20:50:50 <harlowja> any other things people want to talk about?
20:50:59 <harlowja> no question turned away :)
20:51:25 <adrian_otto> I hve a question about backends
20:51:42 <adrian_otto> the current patch (sorry no link on hand) implements a ZX backend
20:51:50 <adrian_otto> I saw a Dummy.py in there
20:52:06 <adrian_otto> there was discussion of in-memory in the past meeting
20:52:15 <harlowja> yup, i think dummy -> in-memory
20:52:26 <adrian_otto> do we need a simple on-disk version?
20:52:51 <harlowja> could be, i guess it depends on which primitive u want to back by disk
20:53:10 <harlowja> but i could imagine a task-log being backed by sqllite for example
20:53:20 <harlowja> a locking mechanism also, could be using filelocks
20:53:50 <harlowja> a type of job 'availability' board though would be a little odd to just have in-memory, but for testing it seems important
20:54:38 <harlowja> so adrian_otto  i think we could have that :)
20:55:06 <harlowja> but might need to know more about which piece u are thinking about
20:55:06 <adrian_otto> so just about every workflow in Nova is vulnerable to a service restart
20:55:11 <harlowja> yup
20:55:16 <harlowja> *or power failure
20:55:22 <adrian_otto> and we won't likely take a ZK dependency by default
20:55:26 <harlowja> yup
20:55:44 <adrian_otto> so having something that works well on a single node, and survives restarts (even if crash recovery process is needed) will be useful
20:55:51 <harlowja> so i think it would be local, in-memory, DB impl, then maybe a ZK impl
20:56:09 <harlowja> *in-memory mainly for testing
20:56:15 <adrian_otto> the DB impl might be sketchy for stuff like locks
20:56:19 <harlowja> yup
20:56:24 <adrian_otto> so it might need to be a combination
20:56:32 <harlowja> agreed
20:56:53 <adrian_otto> I trust fcntl() and flock() but not MySQL GET_LOCK or whatever
20:56:55 <harlowja> can u expand on that idea, like i think i know the scenario u are thinking of, but might not be :)
20:57:06 <jlucci> I think we only need a DB impl for completed jobs
20:57:08 <harlowja> *as time runs out :(
20:57:19 <jlucci> an executing job doesn't need to persist in a DB
20:57:26 <adrian_otto> indeed. where can we capture this as an item for further discussion?
20:57:56 <harlowja> i can capture, but might be useful to continue on another channel, or ML?
20:58:06 <harlowja> so many good idears :)
20:58:30 <harlowja> *would rather not wait a week to talk about them
20:58:35 <adrian_otto> ok, tx, that's it for now on this subject
20:58:48 <adrian_otto> will follow up after meeting to keep it moving
20:58:53 <harlowja> cool
20:59:06 <harlowja> 1 minute left!
20:59:13 <harlowja> i'll capture this stuff and send it out
20:59:31 <glikson> good progress :-)
20:59:39 <harlowja> def
20:59:43 <harlowja> thx all!
20:59:51 <harlowja> #endmeeting