[openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

Chris Friesen chris.friesen at windriver.com
Fri Jan 19 15:21:32 UTC 2018

On 01/18/2018 02:54 PM, Mathieu Gagné wrote:

> We use this feature to segregate capacity/hosts based on CPU
> allocation ratio using aggregates.
> This is because we have different offers/flavors based on those
> allocation ratios. This is part of our business model.
> A flavor extra_specs is use to schedule instances on appropriate hosts
> using AggregateInstanceExtraSpecsFilter.
> Our setup has a configuration management system and we use aggregates
> exclusively when it comes to allocation ratio.
> We do not rely on cpu_allocation_ratio config in nova-scheduler or nova-compute.
> One of the reasons is we do not wish to have to
> update/package/redeploy our configuration management system just to
> add one or multiple compute nodes to an aggregate/capacity pool.
> This means anyone (likely an operator or other provisioning
> technician) can perform this action without having to touch or even
> know about our configuration management system.
> We can also transfer capacity from one aggregate to another if there
> is a need, again, using aggregate memberships. (we do "evacuate" the
> node if there are instances on it)
> Our capacity monitoring is based on aggregate memberships and this
> offer an easy overview of the current capacity. Note that a host can
> be in one and only one aggregate in our setup.

The existing mechanisms to control aggregate membership will still work, so the 
remaining issue is how to control the allocation ratios.

What about implementing a new HTTP API call (as a local private patch) to set 
the allocation ratios for a given host?  This would only be valid for your 
scenario where a given host is only present in a single aggregate, but it would 
allow your techs to modify the ratios.


More information about the OpenStack-dev mailing list