openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

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

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?

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 abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.