Open Stack

On 01/19/2018 10:21 AM, Chris Friesen wrote:
> 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.

The problem is the nova-compute will override the placement inventory 
records' allocation_ratio field with the value of the nova.cnf 
CONF.$resource_allocation_ratio options each time the 
update_available_resource() periodic task runs. :(

That's why the solution needs some way of disabling that behaviour.

Best,
-jay