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. thanks -Doug ______________________________________________________ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | dug at us.ibm.com The more I'm around some people, the more I like my dog. Devin Carlen <devin at openstack.org> Sent by: openstack-bounces+dug=us.ibm.com at lists.launchpad.net 06/27/2012 03:53 PM To "openstack at lists.launchpad.net (openstack at lists.launchpad.net)" <openstack at lists.launchpad.net> cc Subject [Openstack] Nova and asynchronous instance launching We filed a blueprint for this yesterday: https://blueprints.launchpad.net/nova/+spec/launch-instances-async "Currently if a user attempts to create a lot of instances with a single API call (using min_count) the request will hang for a long time while all RPC calls are completed. For a large number of instances this can take a very long time. The API should return immediately and asynchronously make RPC calls." We are looking for creative ways to work around this problem, but in the meantime I'd like to hear from folks on what they think the preferred solution would be. Devin_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack at lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120627/92961d92/attachment.html>