openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #02492
Re: OpenStack API, Reservation ID's and Num Instances ...
On May 23, 2011, at 11:41 AM, Jorge Williams wrote:
> I don't see how that peculates anything. Treat the instance id as the reservation id on single instance creations -- have a separate reservation id when launching multiple instances. End of the day even if you have the capability to launch multiple instances at once you should be able to poll a specific instance for changes.
I'm not too crazy about an API call returning one thing (instance ID) for one call, and a different thing (reservation ID) for the same call, with the only difference being the value of one parameter. Do we do anything like that anywhere else in the API?
Also, with distributed zones, getting an instance ID requires the api to block until the host selection can be completed, and the host's zone database updated with the new instance information. Granted, that's not an agonizingly slow or expensive operation even if it does involve several inter-zone HTTP calls, but it isn't the cleanest and most scalable design IMO.
-- Ed Leafe
Follow ups
References
-
OpenStack API, Reservation ID's and Num Instances ...
From: Sandy Walsh, 2011-05-23
-
Re: OpenStack API, Reservation ID's and Num Instances ...
From: Jorge Williams, 2011-05-23
-
Re: OpenStack API, Reservation ID's and Num Instances ...
From: Jay Pipes, 2011-05-23
-
Re: OpenStack API, Reservation ID's and Num Instances ...
From: Jorge Williams, 2011-05-23
-
Re: OpenStack API, Reservation ID's and Num Instances ...
From: Ed Leafe, 2011-05-23
-
Re: OpenStack API, Reservation ID's and Num Instances ...
From: Jorge Williams, 2011-05-23