On May 23, 2011, at 10:15 AM, Jay Pipes wrote: > /me wishes you were on IRC ;) > > Discussing this with Mark Wash on IRC... >
I'll stop by :-) > Basically, I'm cool with using a UUID-like pregenerated instance ID > and returning that as a reservation ID in the 1.X API. Cool. > 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. > Okay, I'll follow up. > 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
