Open Stack

> Hi Phil and Jay,
>
>Phil, maybe you remember I discussed with you about the possibility of using pclouds with Climate, but we finally ended up using Nova aggregates and a dedicated filter. 
>That works pretty fine. We don't use instance_properties 
>but rather aggregate metadata but the idea remains the same for isolation.

Sure do, and I had a question around that which has been buzzing in my head for a while now.

I can see how you can use an aggregate as a way of isolating the capacity of some specific hosts (Pclouds was pretty much doing the same thing - it was in effect an abstraction layer to surface aggregates to users), and I can see that you can then plan how to use that capacity against a list of reservations.

It does though seem that you're confined to working on some subset of the physical hosts, which I'd of thought could become quite restrictive in some cases and hard to optimize for capacity.  (if for example a user wants to combine reservations with anti-affinity then you'd need to have a larger pool of hosts to work with).

It sort of feels to me that a significant missing of having a reservation system for Nova is that there is no matching concept within Nova of the opposite of a reservation - a spot instance (i.e an instance which the user gets for a lower price in return for knowing it can be deleted by the system if the capacity is needed for another higher-priority request - e.g. a reservation).

If we had a concept of spot instances in Nova, and the corresponding process to remove them, then the capacity demands of reservations could be balanced by the amount of spot-instance usage in the system (and this would seem a good role for an external controller). 

I'm wondering if managing spot instances and reservations across the whole of a Nova system wouldn't be a more general use case than having to manage this within a specific aggregate - or am I missing something ?

Cheers,
Phil