openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

/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.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
>>>
>>>
>
>