19:59:41 <harlowja> #startmeeting openstack-state-management
19:59:42 <openstack> Meeting started Thu Jan 23 19:59:41 2014 UTC and is due to finish in 60 minutes.  The chair is harlowja. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:59:45 <openstack> The meeting name has been set to 'openstack_state_management'
20:00:21 <harlowja> hi all
20:00:28 <ekarlso> yo
20:00:32 <haruka_> hi
20:00:37 <harlowja> hi hi
20:01:17 * harlowja waiting a few
20:03:12 <iv_m> hi there
20:03:17 <harlowja> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/025168.html
20:03:24 <harlowja> just got out of meeting, didn't update agenda yet
20:03:28 <harlowja> but thats the agenda ^
20:04:19 <harlowja> hi iv_m ekarlso thx for coming :)
20:04:25 <harlowja> guess small meeting today
20:04:31 <harlowja> #topic action-items
20:04:36 <harlowja> #link http://eavesdrop.openstack.org/meetings/openstack_state_management/2014/openstack_state_management.2014-01-16-20.00.html
20:04:51 <harlowja> so i didn't do mine yet, still, bugging infra about zookeeper
20:04:53 <harlowja> :(
20:05:09 <harlowja> but would rather let infra folks calm down and not both them with to much for a little while
20:05:13 <harlowja> due to all the gate issues and stuffs
20:05:30 <harlowja> so i'll try to do that soon, along with the review for config changes that we have up
20:06:23 <harlowja> #action harlowja followup when infra calms down about zookeeper test usage
20:06:38 <harlowja> #action harlowja followup when infra calms down about venv conf changes
20:06:55 <iv_m> while we are waiting for config changes, what do u thing about https://review.openstack.org/68622 ?
20:07:28 <harlowja> seems fine
20:07:38 <harlowja> test maximal dependencies instead of minimal right?
20:07:56 <iv_m> ya
20:08:06 <harlowja> k, seems ok to me
20:08:21 <harlowja> thx iv_m
20:08:23 <iv_m> i think most people would use pyXY envs as default ones
20:08:35 <harlowja> agreed
20:09:31 <harlowja> alright cool, lets go onto next interesting topic
20:09:35 <harlowja> #topic oslo-taskflow
20:09:49 <harlowja> so there has been some back and forth for the last week or 2 or 3 about taskflow + oslo
20:09:57 <harlowja> so maybe we can come to some conclusion on it
20:10:02 <harlowja> #link https://etherpad.openstack.org/p/oslo-taskflow
20:10:30 <harlowja> to me the benefits could outweight the drawbacks, but its an unknown process, so its hard to predict what could/couldn't happen
20:12:07 <harlowja> talking with dhellmann i think he's fine with helping work through the process if we do it, maintain our independence and see what happens
20:12:25 <harlowja> *after the infra stuff changes, since it will have side-efffects for infra team (the changes and all that)
20:13:00 * dhellmann perks up his ears
20:13:08 <harlowja> and we can help establish the rules for libraries like taskflow, how/what does it mean to be in oslo, what does it mean to have 2 PTLs (in a way)
20:13:28 <harlowja> dhellmann just was discussing about oslo,vsnot
20:13:41 <dhellmann> yeah, I was thinking of something similar to the lieutenant model, where there's a lead maintainer for each library
20:13:58 <harlowja> k
20:14:07 <harlowja> what would general doug then do i guess?
20:14:19 <dhellmann> I'd be happy to have taskflow in oslo, but don't want to have to take over leadership directly, which I think matches what you want?
20:14:20 <dhellmann> heh
20:14:30 <dhellmann> report to admiral ttx
20:14:55 <harlowja> agreed, thats what i'd like, but its like 2/3 levels of management, so unsure what that implies i guess
20:15:03 <harlowja> *2/3 new levels
20:15:15 <harlowja> as long as taskflow behaves, it doesn't seem like much changes?
20:15:46 <dhellmann> well, I'd just be there to keep you from having another weekly meeting and you'd do all of the triage, scheduling, etc. as you do now
20:16:11 <harlowja> hmmm
20:16:15 <harlowja> less meetings ftw
20:16:20 <dhellmann> right
20:16:47 <harlowja> changbl yt, iv_m what are your thoughts
20:16:57 <harlowja> *some of the other cores
20:18:11 <harlowja> i am personally fine with doing it and seeing what happens
20:18:22 <harlowja> help work through the *bugs* in the process
20:19:10 <harlowja> dhellmann u just make sure pbr is like releasing on xyz date, making sure communication is there, stuff like that right?
20:19:14 <iv_m> it's still unclear to me, what does it mean to be in oslo -- what will change, initally, beside repo url and organizational structure?
20:19:29 <dhellmann> harlowja: yeah, that's the idea
20:19:54 <harlowja> iv_m so oslo i don't think would change otherwise initially
20:19:59 <dhellmann> iv_m: the benefit is you can run pre-release code in the gate tests against the rest of openstack
20:20:44 <dhellmann> which means that openstack apps that rely on taskflow won't be able to introduce breaking changes in the way they use the library
20:20:50 <dhellmann> and vice versa
20:21:58 <harlowja> dhellmann with say only using stable versions of taskflow, in those apps, we'd only introduce anything that could change/cause breakage across stable versions (if at all)
20:22:07 <harlowja> but i guess it does allow for earlier detection of that issue
20:22:37 <dhellmann> harlowja: if the tests only run against stable released versions of taskflow, you'd have to do pre-release testing yourself
20:23:10 <harlowja> right, something that it'd be nice to have machines do
20:23:16 <harlowja> instead of us meat bags
20:23:17 <harlowja> lol
20:23:19 <iv_m> but we are introducing breaking changes from time to time -- we're still 0.1; harlowja is trying to introduce one right now
20:24:57 <harlowja> so iv_m is that good or bad to be integrated into the gate tests then?
20:25:06 <harlowja> it'd allow for earlier fixing for said breaking changes
20:26:06 <harlowja> *earlier fixing and detection
20:27:09 <harlowja> earlier detection would seem like a nice benefit right?
20:27:21 <harlowja> instead of only on release detection
20:28:52 <harlowja> anyways, i guess we can discuss more offline and keep on thinking about this
20:29:05 <dhellmann> yep, it's totally up to you guys
20:29:09 <harlowja> seems like still undecided/not agreed :)
20:29:11 <harlowja> thx dhellmann
20:32:19 <harlowja> #topic checkpoints
20:33:05 <harlowja> so i think changbl was wondering why checkpoints last week, i gave a basic explanation, changbl u around?
20:33:30 <harlowja> i think i get the idea and the impl seems fine to start (although still i think the name can be changed to refeclt more of what the object does)
20:33:34 <harlowja> *reflect
20:34:14 <harlowja> so i am thinking iv_m that we might want to writeup some little tutorial/more detailed wiki on it?
20:34:23 <harlowja> to make sure that the controller idea is well understood by others
20:34:33 <harlowja> *controller seems like the rename that might happen to avoid checkpoint name confusion
20:36:15 <iv_m> #action iv_m akarpinska wiki writeup on reversion strategies
20:36:24 <iv_m> #link https://blueprints.launchpad.net/taskflow/+spec/reversion-strategies
20:36:33 <iv_m> ^^ which is goal for current checkpointing work
20:36:59 <iv_m> https://review.openstack.org/#/q/status:open+project:stackforge/taskflow+branch:master+topic:checkpoints,n,z
20:37:12 <iv_m> ^^ which is current work in progress
20:38:49 <harlowja> thx iv_m, be good to have a example maybe, how its used, i know there are some in the reviews, but twiki might be simpler to just referernce quickly with a summary
20:39:35 <iv_m> there was a writeup on google docs, i think it wan't be hard to update it with our current understanding and move to wiki
20:39:54 <harlowja> cool
20:40:03 <harlowja> i do remember some doc somewhere, that seems like a good move
20:40:06 <harlowja> *to twiki
20:40:44 <harlowja> #topic scoping
20:41:04 <harlowja> so to me this is another intersting one, especially the changes it could involve, brings up some intersting questions
20:41:38 <harlowja> #action harlowja writeup little wiki with a similar explanation as checkpoint/reversion/controller strategies
20:42:13 <harlowja> iv_m i've been wanting to see if u think we should try to do this in a way that is mostly harmless to current users (the engine helpers change is the big api difference)
20:42:34 <harlowja> https://review.openstack.org/#/c/68263/ would allow for backwards compat (basically assume always anonymous)
20:42:59 <ekarlso> what is the changes ?
20:43:26 <harlowja> so short summary, u create a flow with nested subflows right, ..., to do sometype of work
20:43:58 <harlowja> when running, currently we track details about what is running and the states and persisted data in a logbook flowdetail container (which is backed by some backend)
20:45:09 <harlowja> but when u nested subflows (especially when u associate a name to those subflows) it seems like it makes sense to match those named subflows up with there own flowdetail container instead of just using a single flowdetail container
20:45:24 <harlowja> this complicates lookup, but does seem a little more natural (to me at least)
20:45:50 <iv_m> and to me not exactly more natural ;)
20:45:58 <harlowja> :)
20:46:14 <iv_m> so we can arugue, but u'll win because u're typing faster
20:46:17 <harlowja> so it raises the question of what are subflows (especially subflows with names)
20:46:19 <harlowja> lol
20:46:22 <harlowja> hahaha
20:46:44 <harlowja> i'll type more slowly now
20:47:20 <iv_m> to me, subflow names we always mere debugging aid aimed to help to understand what's hapining in flattening and around
20:47:21 <harlowja> does that somewhat make sense ekarlso ?
20:47:35 <iv_m> what i was more intersted was state
20:48:10 <iv_m> i mean, currently subflows don't have separate separate states, and in your scoping patch thay don't have states also -- they share one state
20:48:34 <iv_m> which is then saved in all the flow details
20:49:31 * harlowja thinking
20:49:33 <iv_m> not having hierarchy of states was one of the main reasons i did not want hierarchy of flow details
20:50:09 <iv_m> and i'm still a bit afraid of complexity it introduces
20:51:19 <harlowja> agreed
20:51:41 <harlowja> i agree on the state thing, its not independent state-machines (in a way)
20:52:36 <harlowja> maybe easier/better to figure out how to make it independent state-machines before this change (and see what that loosk like)
20:52:49 <harlowja> hierachical state-machines here we come, lol
20:53:48 <harlowja> so maybe we can shelve this patch for a little while
20:54:06 <harlowja> seem ok?
20:54:55 <iv_m> i'd better avoid herarchical states entierly
20:55:11 <harlowja> not sure if we can in the end :)
20:55:54 <harlowja> anyways, ok, i'll shelve this for a little while, maybe can revisit laterish
20:56:09 <harlowja> and quick last topic before out of time
20:56:11 <harlowja> #topic 0.2
20:56:28 <harlowja> so i think we want to get through the checkpointing code right, and the zookeeper 2/3 reviews
20:56:42 <harlowja> does that seem doable, i think those are almost done and just need some further reviewing
20:56:52 <harlowja> so maybe next week we could have 0.2?
20:57:12 <harlowja> it'd be nice to have https://review.openstack.org/#/c/65135/ go through also
20:57:17 <harlowja> *depending on gate situations*
20:57:21 <changbl> hi, guys, sorry i am late
20:57:26 <harlowja> np
20:57:28 <changbl> harlowja, i was in a meeting
20:57:31 <harlowja> 2 minutes :-P
20:57:32 <harlowja> haha
20:57:33 <changbl> :)
20:57:36 <harlowja> all good
20:57:41 <changbl> any thing for me to do/look at?
20:57:57 <harlowja> just talking about 0.2
20:58:04 <changbl> next week?
20:58:11 <harlowja> i was thinking the checkpoint code (renamed i think to controller code), zookeeper 3 patches
20:58:15 <harlowja> and that'd be ok for 0.2?
20:58:25 <harlowja> most of the above is just going through final reviews anyway
20:58:35 <harlowja> reviews and tweaks
20:58:43 <harlowja> so next week does seem achievable right?
20:58:52 <changbl> zookeeper fine with me
20:59:13 <harlowja> and i guess worker model also iv_m , do u feel stanislav will be ok with that in 0.2?
20:59:21 <harlowja> that ones the other big neat feature
20:59:31 <harlowja> https://review.openstack.org/#/c/63155/
20:59:44 <harlowja> changbl if u want to check that out, its coming along, seems like a good chunk of code
21:00:04 <harlowja> alot for one commit/review, but pretty seperated anyway
21:00:08 <harlowja> crap
21:00:09 <harlowja> time up
21:00:17 <harlowja> go to #openstack-state-management for more!
21:00:21 <harlowja> #endmeeting