20:03:47 <harlowja> #startmeeting openstack-state-management
20:03:47 <openstack> Meeting started Thu Apr  3 20:03:47 2014 UTC and is due to finish in 60 minutes.  The chair is harlowja. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:50 <openstack> The meeting name has been set to 'openstack_state_management'
20:04:01 <harlowja> so this is the second fun meeting today
20:04:13 <harlowja> i sorta messedup the other meeting, lol, wrong time ;
20:04:14 <harlowja> ;)
20:04:23 <harlowja> #link https://wiki.openstack.org/wiki/Meetings/StateManagement#Agenda_for_next_meeting
20:04:42 <harlowja> the stuff from last meeting, 1 hour ago, lol
20:04:42 <harlowja> http://eavesdrop.openstack.org/meetings/openstack_state_management/2014/openstack_state_management.2014-04-03-19.00.html
20:05:15 <harlowja> #topic time-shift
20:05:27 <harlowja> iv_m so 1900 UTC is better for u right
20:05:38 <iv_m> yup, thanks a lot!
20:06:01 <harlowja> np, just lets u sleep a little i guess
20:06:02 <harlowja> lol
20:06:08 <harlowja> more sleep, lol
20:07:01 <harlowja> for the 0.2.1 do u think thats fine iv_m , from last hour ago meeting, just some small fixes
20:07:31 <harlowja> mainly some small blueprints and any other bugs we find
20:08:11 <iv_m> harlowja: looks good
20:08:15 <harlowja> kk
20:08:25 <harlowja> changbl yt
20:08:59 <harlowja> as for 0.3, i was thinking we can go through the current BPs and tag them
20:09:11 <harlowja> and depending on what the mistral collaboration is we can figure out other new ones
20:10:00 <harlowja> lets jump into that, and maybe we can discuss that a little
20:10:08 <harlowja> #topic mistral-engine-ideas
20:10:36 <harlowja> i think the idea is becoming more clear, and i think it may not actually be that big of a change
20:11:05 <harlowja> basically an engine that doesn't keep active while running (but could do 1 execution iteration, and stop and repeat...)
20:11:23 <harlowja> and then it can be mistral that does all the iterations on its own time
20:12:00 <harlowja> dkrause also had the idea of allowing tasks to write there own logbook data so that the engine doesn't even have to do that on there behalf
20:12:15 <harlowja> that would make the engine do even less (or could do less, depending on the selected engine type)
20:12:31 <harlowja> it would still allow us to retain the existing types (which would just be the 'all in one' solution)
20:13:01 <iv_m> tasks saving their own results?
20:14:07 <dkrause> it would allow us to stop the engine while tasks were still running remotely (for engines that don't run tasks in the same process as the engine)
20:14:08 <harlowja> ya, i'm not 100% clear on it also, but i think instead of an engine interacting with storage, task itself could in some cases save its own failure/result into the storage backend (in some cases, failures may not be possible to do this, especially if task/worker running task crashes)
20:15:39 <iv_m> that practically makes database open for remote workers; nova invented conductor to avoid it
20:16:04 <harlowja> it would make what is suspension a little hard to define, since an engine can suspend itself, but tasks could actually still be running (which would make the resuming part a little awkard, since if a engine is resumed before the previous tasks that were running before suspension finished that might be odd)
20:16:20 <harlowja> iv_m thats a good point
20:16:45 <dkrause> hmm... so what mechanism would a task use to notify a conductor of it's results?
20:16:53 <dkrause> assuming there's no running engine
20:17:09 <iv_m> resuming while tasks are running is on our list anyway; without it it is hard to resume e.g. worker-based engine properly
20:17:24 <harlowja> i think there has to be a running something, either an entrypoint the tasks could call (like a rest endpoint)
20:18:13 <harlowja> the task finishes right now, it sends a response back to the engine via MQ (but it could send a response to some other entrypoint, that isn't an engine, but a engine-factory that would do the next execution iteration)
20:18:22 <harlowja> i think thats part of the mistral idea
20:19:17 <dkrause> if the conductor used a polling model, the results could be passed back through the queue, but that might not be what mistral is looking for
20:21:05 <dkrause> that is, a conductor would be required to keep engine instances (though not running ones) and have them poll for results periodically
20:21:11 <harlowja> i think there thinking of something more like allowing some thing other than the running engine to be a results reciever, this reciever could then reconstruct the engine (that now isn't running) and figure out what to do next with whatever results were given
20:21:37 <harlowja> dkrause ya, it could possibly be something like that
20:21:43 <harlowja> although i'd rather not poll if we can :-/
20:22:12 <iv_m> dkrause: i don't see why polling would be required
20:23:16 <harlowja> the conductor could watch (for example) a zookeeper directory that tasks would write into and then zookeeper will notify the conductor automagically
20:24:10 <harlowja> anyways
20:24:18 <harlowja> lots of ideas :)
20:24:21 <iv_m> afaik mistral exposes http entry point for workers to report to; our worker-based engine does pretty much the same but with amqp
20:24:27 <harlowja> iv_m right
20:24:36 <iv_m> * or kombu virtual transports
20:24:39 <harlowja> right
20:25:05 <iv_m> i wrote some thoughs on 'lazy engine' idea to ML about an hour ago
20:25:11 <harlowja> ah, k, will check
20:25:32 <iv_m> i short, i don't think engine interface should be affected
20:25:48 <harlowja> hmmm, intersting
20:25:49 <iv_m> instead, we might refactor and make task executors public
20:26:00 <harlowja> not something like run_iter()
20:26:05 <harlowja> that could be useful (maybe)
20:26:24 <iv_m> run_iter looks too internal
20:26:42 <iv_m> i think i would like to see separation of concens
20:27:01 <harlowja> kk, will checkout ML
20:27:02 <iv_m> one concern is to run a flow -- prepare tasks and patterns, load it to engine, and so on
20:27:40 <iv_m> maybe we'll need API to 'run and forget' -- a call that will schedule a flow but not wait for completion
20:27:51 <iv_m> another concern is executing tasks
20:28:56 <iv_m> task executors don't need to know anything about flows or engines or engine internals
20:29:57 <harlowja> intersting, will think it over
20:30:26 <dkrause> I definitely like the idea of a decoupled task executor
20:30:42 <iv_m> executors may be shared between engines and just colling provided callbacks, or setting resutls to futures which is pretty much same thing but with somewhat different implications
20:31:25 <iv_m> i think i'll try to experiment with callback-based task executor interface on weekend
20:31:42 <dkrause> I don't see how this will help with the problem that our current engine model is synchronous
20:32:09 <dkrause> "run" is expected to return only after a completed flow
20:32:40 <dkrause> how are we going to accomplish a "lazy engine" with this model?
20:33:24 <iv_m> as i said above, what whe might need is just something like 'run_async' in engine interface that schedules the flow but not waits for its completion -- e. g. retuns future, or we can just rely on notifications
20:33:46 <iv_m> that can be easily done even with current engines
20:34:10 <iv_m> #link https://blueprints.launchpad.net/taskflow/+spec/share-engine-thread related to that
20:34:26 <harlowja> so run_async returns future, then mistral can basically throw that future away if it wants?
20:34:41 <harlowja> and just wait for some notifications to do more actions?
20:35:18 <harlowja> *whatever those actions are*
20:36:19 <harlowja> hmmm, i wonder how this would work, if mistral also replaces task_executors with something of its own
20:36:40 <iv_m> smooooothly;)
20:36:47 <harlowja> ;)
20:36:56 <harlowja> maybe i guess a small example code would make it more clear
20:37:10 <harlowja> i sorta get the idea (maybe), ha
20:37:35 <iv_m> ok
20:37:44 <harlowja> dkrause sounds ok? maybe more clear with some code ;)
20:38:15 <iv_m> #action iv_m describe idea on lazy engine with executors on wiki or somewhere, with code examples if possible
20:38:22 <harlowja> sounds great
20:38:30 <harlowja> thx iv_m :)
20:38:45 <dkrause> yeah, I'd like to see details on how callbacks are handled - it sounds good, but there are some pieces that are unclear to me
20:39:07 <harlowja> agreed, i'll have to let my brain think it over a little to
20:39:26 <iv_m> well, i guess when all pieces are cleare all's left is to press couple of gerrit buttons
20:39:42 <harlowja> +2
20:39:43 <harlowja> lol
20:40:45 <harlowja> hopefully the mistral peopel can get involved in coding this to, that'd be nice
20:41:31 <harlowja> alright, lets openup for anything else
20:41:34 <harlowja> #topic open-discuss
20:42:03 <harlowja> dkrause another idea we've been thinking about is instead of doing iterjobs and such, we should also provide such callback interface to be notified of new jobs appearing
20:42:12 <harlowja> just didn't get around to it for 0.2
20:42:18 <harlowja> i think that'd probably be useful for your case
20:42:28 <dkrause> it definitely would
20:42:30 <harlowja> to avoid all the looping crap
20:42:32 <harlowja> k
20:42:47 <harlowja> let me see if i can expose that, although i'm not sure how something like redis would work in this manner
20:43:00 <harlowja> zookeeper has 'watches' that can provide this, but redis or others not really sure
20:43:05 <dkrause> which brings up the question: is this actually a "conductor", or is that concept entirely different from what I proposed here? https://blueprints.launchpad.net/taskflow/+spec/generic-flow-conductor
20:43:44 <harlowja> hmmm, it seems like a conductor to me, although naming isn't my strong suit :)
20:44:26 <harlowja> could be called jobmanager to, but seems the same
20:44:28 <dkrause> I feel like what I'm proposing there is very useful, but I also don't want to step on anyone's toes if we're going to define a specific role and interface for something called a conductor
20:44:40 <harlowja> i don't think u steping on anyones toes :)
20:44:45 <harlowja> although nova and others have a conductor
20:44:50 <harlowja> but in concept there's is similar
20:44:57 <harlowja> it does some work onbehalf of others
20:45:06 <harlowja> *conducts work on behalf of others
20:46:09 <harlowja> the mistral interconnect could also be a conductor, although that i think is to much unknown so far
20:46:30 <harlowja> *whatever said mistral interconnect finally is*
20:46:58 <dkrause> alright. I'll keep doing what I'm doing there for now
20:47:02 <harlowja> sounds good
20:47:23 <harlowja> #action harlowja writeup small bp for jobboard 'notification' (not always requiring iteration)
20:47:37 <harlowja> #action harlowja  implement that, ha
20:47:55 <harlowja> cool, anything else to sync up on?
20:48:15 <harlowja> remember switch to 1900 UTC if we need further meetings so that iv_m can sleep more
20:48:57 <harlowja> gooing once
20:49:07 <iv_m> #info state management meeting moved to Thu, 1900 UTC
20:49:14 <harlowja> thx :)
20:49:19 * iv_m always wanted to try that command =)
20:49:19 <harlowja> going twiiiceeee
20:49:36 <harlowja> and sold to iv_m
20:49:40 <harlowja> #endmeeting