Open Stack

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