openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #02482
Re: OpenStack API, Reservation ID's and Num Instances ...
Sandy,
If I understand the features correctly, their implementation in nova seems straightforward. However, I am still a little curious about their necessity. For load balancing, what is the difference between a single request for N instances and N requests for a single instance each?
"Sandy Walsh" <sandy.walsh@xxxxxxxxxxxxx> said:
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
> 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.
>
>
Follow ups