I'd like to step back and denote that there won't be support for this in the 1.1 API -- unless this is an extension. So this is 2.0 API stuff -- right. Other comments inline:
On May 23, 2011, at 10:53 AM, Sandy Walsh wrote: Cool, I think you all understand the concerns here: 1. We can't treat the InstanceID as a ReservationID since they do two different things. InstanceID's are unique per instance and ReservationID's might span N instances. I don't like the idea of overloading these concepts. How is the caller supposed to know if they're getting back a ReservationID or an InstanceID? How to they ask for updates for each (one returns a single value, one returns a list?). The user doesn't even need to know that there are two concepts at all -- at least not in the 1.1 world. When creating single instances then they only see a single instance ID. 2. We need to handle "provision N instances" so the scheduler can effectively load balance the requests by looking at the current state of the system in a single view. Concurrent single-shot requests would be picked up by many different schedulers in many different zones and give an erratic distribution. 3. As Soren pointed out, we may want certain semantics around failure such as "all or nothing" 4. Other Nova users have mentioned a desire for instance requests such as "has GPU, is in North America and has a blue sticker on the box". If we try to do that with Flavors we need to clutter the Flavor table with most-common-denominator fields. We can handle this now with Zone/Host Capabilities and not have to extend the table at all. If you look at nova/tests/scheduler/test_host_filter.py you'll see an example of this in action. To Soren's point about "losing the ability to rely on a fixed set of topics in the message queue for doing scheduling" this is not the case, there are no new topics introduced. Instead there are simply extra arguments passed into the run_instance() method of the scheduler that understands these more complex instance requests. That said, I was thinking of adding a POST /zone/server command to support these extended operations. It wouldn't affect anything currently in place and makes it clear that this is a zone-specific operation. Existing EC2 and core OS API operations are performed as usual. Likewise, we need a way to query the results of a Reservation ID request without busting GET /servers/detail ... perhaps GET /zones/servers could do that? Why not simply have a request on the server list with the reservation id as a parameter. This can easily be supported as an extension. So GET /servers/detail?RID=3993882 I would probably call it a build ID. That would narrow the response to only those that are currently being build with a single request (3993882). The downside is that now we have two ways to create an instance that needs to be tested, etc. -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 ab...@rackspace.com<mailto:ab...@rackspace.com>, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
