Open Stack

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?

Or am I missing something here?
-jay