openstack team mailing list archive

[Monsyne Dragon <mdragon@xxxxxxxxxxxxx>]

On Aug 26, 2011, at 6:41 PM, John Dickinson wrote:

> 
> 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/).

Somewhat.  It's a pretty common, simplified 'workflow' type design.  Basically a glorified visitor pattern.    I just avoided the term, because I think we only need a fairly simple, specific, implementation, not the be-all, end-all all-singing-all-dancing dessert topping and floor wax that most things labeled 'workflow' tend to try to be. :>  

--
	Monsyne M. Dragon
	OpenStack/Nova 
	cell 210-441-0965
	work x 5014190

This email may include confidential information. If you received it in error, please delete it.