Open Stack

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 at RACKSPACE.COM> said:

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