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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
