On Aug 26, 2011, at 6:10 PM, Monsyne Dragon wrote: > > The proper way, IMHO, for this to work is that a request generates a > workorder with a set of tasks. > This gets sent to something (scheduler, probably) which looks at the first > uncompleted task on the workorder, makes the decision on where to send it, > and routes the whole workorder there. > The service that gets it performs the task (i.e. executes the method), > possibly attaching info (like id of newly created instance) to the > workorder, and possibly pushing an 'undo' task to the top of a list of tasks > to perform if things fail somewhere. > Then the whole workorder gets sent back to the origin (again, scheduler?) > This looks at the next uncompleted task, and starts the cycle again. > Repeat until done. > > If there is a failure, the scheduler works through the 'undo' list on the > workorder, and then makes whatever decisions are needed to redo the tasks > elsewhere. The workorder contains the record of the failed attempt, so it > doesn't, for example, try to send the server build back to the same hosts > that just failed. > > The workorder acts as an environment for the tasks, and could be passed to > tasks (rpc methods) as an attribute of the context object.
This sounds very similar to Google's app engine pipeline project (http://code.google.com/p/appengine-pipeline/). _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
