Comments inline: On May 23, 2011, at 8:59 AM, Jay Pipes wrote:
> Hi Jorge! Comments inline :) > > On Mon, May 23, 2011 at 9:42 AM, Jorge Williams > <jorge.willi...@rackspace.com> wrote: >> Hi Sandy, >> My understanding (Correct me if i'm wrong here guys) is that creating >> multiple instances with a single call is not in scope for the 1.1 API. > > Actually, I don't think we *could* do this without issuing a 2.0 API. > The reason is because changing POST /servers to return a reservation > ID instead of the instance ID would break existing clients, and > therefore a new major API version would be needed. Why? Clients just see an ID. I'm suggesting that for single instances, the instanceID == the reservationID. In the API you query based on Some ID. http://my.openstack-compute.net/v1.1/2233/servers/{Some unique ID} > >> Same >> thing for changing the way in which flavors work. Both features can be >> brought in as extensions though. > > Sorry, I'm not quite sure I understand what you mean by "changing the > way flavours work". Could you elaborate a bit on that? Sandy was suggesting we employ a method "richer than Flavors". I'll let him elaborate. > >> I should note that when creating single instances the instance id should >> really be equivalent to a reservation id. That is, the create should be >> asynchronous and the instance id can be used to poll for changes. > > Hmm, it's actually a bit different. In one case, you need to actually > get an identifier for the instance from whatever database (zone db?) > would be responsible for creating the instance. In the other case, you > merely create a token/task that can then be queried for a status of > the operation. In the former case, you unfortunately make the > scheduler's work synchronous, since the instance identifier would need > to be determined from the zone the instance would be created in. :( > If we make the instance ID a unique ID -- which we probably should. Why not also treat it as a reservation id and generate/assign it up front? >> Because >> of this, a user can create multiple instances in very rapid succession. > > Not really the same as issuing a request to create 100 instances. Not > only would the user interface implications be different, but you can > also do all-or-nothing scheduling with a request for 100 instances > versus 100 requests for a single instance. All-or-nothing allows a > provider to pin a request to a specific SLA or policy. For example, if > a client requests 100 instances be created with requirements X, Y, and > Z, and you create 88 instances and 12 instances don't get created > because there is no more available room that meets requirements X, Y, > and Z, then you have failed to service the entire request... > I totally understand this. I'm just suggesting that since this is not is scope for 1.1 -- you should be able to launch individual instances as an alternative. Also, keep in mind that the all-or-nothing requires a compensation when something fails. >> Additionally, the changes-since feature in the API allows a user to >> efficiently monitor the creation of multiple instances simultaneously. > > Agreed, but I think that is tangential to the above discussion. > > Cheers! > jay > >> -jOrGe W. >> On May 23, 2011, at 7:19 AM, Sandy Walsh wrote: >> >> Hi everyone, >> We're deep into the Zone / Distributed Scheduler merges and stumbling onto >> an interesting problem. >> EC2 API has two important concepts that I don't see in OS API (1.0 or 1.1): >> - Reservation ID >> - Number of Instances to create >> Typical use case: "Create 1000 instances". The API allocates a Reservation >> ID and all the instances are created until this ID. The ID is immediately >> returned to the user who can later query on this ID to check status. >> From what I can see, the OS API only deals with single instance creation and >> returns the Instance ID from the call. Both of these need to change to >> support Reservation ID's and creating N instances. The value of the >> distributed scheduler comes from being able to create N instances load >> balanced across zones. >> Anyone have any suggestions how we can support this? >> Additionally, and less important at this stage, users at the summit >> expressed an interest in being able to specify instances with something >> richer than Flavors. We have some mockups in the current host-filter code >> for doing this using a primitive little JSON grammar. So, let's assume the >> Flavor-like query would just be a string. Thoughts? >> -S >> >> >> Confidentiality Notice: This e-mail message (including any attached or >> embedded documents) is intended for the exclusive and confidential use of >> the >> individual or entity to which this message is addressed, and unless >> otherwise >> expressly indicated, is confidential and privileged information of >> Rackspace. >> Any dissemination, distribution or copying of the enclosed material is >> prohibited. >> If you receive this transmission in error, please notify us immediately by >> e-mail >> at ab...@rackspace.com, and delete the original message. >> Your cooperation is appreciated. >> >> _______________________________________________ >> 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 >> >> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
