> 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 

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 ?


OpenStack-dev mailing list

Reply via email to