Given the size and detail of this thread, I've tried to summarize the
problems and possible solutions/workarounds in this etherpad:
https://etherpad.openstack.org/p/nova-aggregate-filter-allocation-ratio-snafu
For those working on this, please check that what I have written down is
correct and then we can try to make some kind of plan for resolving this.
On 1/16/2018 3:24 PM, melanie witt wrote:
Hello Stackers,
This is a heads up to any of you using the AggregateCoreFilter,
AggregateRamFilter, and/or AggregateDiskFilter in the filter scheduler.
These filters have effectively allowed operators to set overcommit
ratios per aggregate rather than per compute node in <= Newton.
Beginning in Ocata, there is a behavior change where aggregate-based
overcommit ratios will no longer be honored during scheduling. Instead,
overcommit values must be set on a per compute node basis in nova.conf.
Details: as of Ocata, instead of considering all compute nodes at the
start of scheduler filtering, an optimization has been added to query
resource capacity from placement and prune the compute node list with
the result *before* any filters are applied. Placement tracks resource
capacity and usage and does *not* track aggregate metadata [1]. Because
of this, placement cannot consider aggregate-based overcommit and will
exclude compute nodes that do not have capacity based on per compute
node overcommit.
How to prepare: if you have been relying on per aggregate overcommit,
during your upgrade to Ocata, you must change to using per compute node
overcommit ratios in order for your scheduling behavior to stay
consistent. Otherwise, you may notice increased NoValidHost scheduling
failures as the aggregate-based overcommit is no longer being
considered. You can safely remove the AggregateCoreFilter,
AggregateRamFilter, and AggregateDiskFilter from your enabled_filters
and you do not need to replace them with any other core/ram/disk
filters. The placement query takes care of the core/ram/disk filtering
instead, so CoreFilter, RamFilter, and DiskFilter are redundant.
Thanks,
-melanie
[1] Placement has been a new slate for resource management and prior to
placement, there were conflicts between the different methods for
setting overcommit ratios that were never addressed, such as, "which
value to take if a compute node has overcommit set AND the aggregate has
it set? Which takes precedence?" And, "if a compute node is in more than
one aggregate, which overcommit value should be taken?" So, the
ambiguities were not something that was desirable to bring forward into
placement.
__________________________________________________________________________
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
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
