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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
