openstack team mailing list archive

[Jorge Williams <jorge.williams@xxxxxxxxxxxxx>]

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.williams@xxxxxxxxxxxxx> 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.williams@xxxxxxxxxxxxx> 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 abuse@xxxxxxxxxxxxx, and delete the original message.
>>>> Your cooperation is appreciated.
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>>> 
>> 
>>