Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 

Thanks,

Matt