← Back to team overview

openstack team mailing list archive

Re: OpenStack API, Reservation ID's and Num Instances ...


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.

> 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?

> 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. :(

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

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


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

Follow ups