Open Stack

On 07/24/2013 05:39 AM, Day, Phil wrote:
> Hi Alex,
> 
> I'm inclined to agree with others that I'm not sure you need the complexity that this BP brings to the system.    If you want to provide a user with a choice about how much overcommit they will be exposed to then doing that in flavours and the aggregate_instance_extra_spec filter seems the more natural way to do this, since presumably you'd want to charge differently for those and the flavour list is normally what is linked to the pricing model.  
> 
> I also like the approach taken by the recent changes to the ram filter where the scheduling characteristics are defined as properties of the aggregate rather than separate stanzas in the configuration file.
> 
> An alternative, and the use case I'm most interested in at the moment, is where we want the user to be able to define the scheduling policies on a specific set of hosts allocated to them (in this case they pay for the host, so if they want to oversubscribe on memory/cpu/disk then they should be able to).  The basic framework for this is described in this BP https://blueprints.launchpad.net/nova/+spec/whole-host-allocation and the corresponding wiki page (https://wiki.openstack.org/wiki/WholeHostAllocation.    I've also recently posted code for the basic framework built as a wrapper around aggregates (https://review.openstack.org/#/c/38156/, https://review.openstack.org/#/c/38158/ ) which you might want to take a look at.
>  
> Its not clear to me if what your proposing addresses an additional gap between this and the combination of the aggregate_extra_spec filter + revised filters to get their configurations from aggregates) ?

I really like your point about not needing to set things up via a config
file.  That's fairly limiting since you can't change it on the fly via
the API.

-- 
Russell Bryant