/me wishes you were on IRC ;) Discussing this with Mark Wash on IRC...
Basically, I'm cool with using a UUID-like pregenerated instance ID and returning that as a reservation ID in the 1.X API. I was really just brainstorming about a future, request-centric 2.0 API that would allow for more atomic operations on the instance creation level. Cheers! jay On Mon, May 23, 2011 at 10:35 AM, Jorge Williams <jorge.willi...@rackspace.com> wrote: > 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