openstack team mailing list archive

[Devin Carlen <devin@xxxxxxxxxxxxx>]

On Jun 28, 2012, at 9:01 AM, Jay Pipes wrote:

> On 06/27/2012 06:51 PM, Doug Davis wrote:
>> Consider the creation of a "Job" type of entity that will be returned
>> from the original call - probably a 202.  Then the client can check the
>> Job to see how things are going.
>> BTW - this pattern can be used for any async op, not just the launching
>> of multiple instances since technically any op might be long-running (or
>> queued) based on the current state of the system.
> 
> Note that much of the job of launching an instance is already asynchronous -- the initial call to create an instance really just creates an instance UUID and returns to the caller -- most of the actual work to create the instance is then done via messaging calls and the caller can continue to call for a status of her instance to check on it. In this particular case, I believe Devin is referring to when you indicate you want to spawn a whole bunch of instances and in that case, things happen synchronously instead of asynchronously?
> 
> Devin, is that correct? If so, it seems like returning a packet immediately that contains a list of the instance UUIDs that can be used for checking status is the best option?

Yep, exactly.  The client still waits synchronously for the underlying RPC to complete.  An immediate 202 would be a great way to deal with this.

> 
> Or am I missing something here?
> -jay
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp