<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 17, 2018 at 2:22 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/16/2018 08:19 PM, Zhenyu Zheng wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the info, so it seems we are not going to implement aggregate overcommit ratio in placement at least in the near future?<br>
</blockquote>
<br></span>
As @edleafe alluded to, we will not be adding functionality to the placement service to associate an overcommit ratio with an aggregate. This was/is buggy functionality that we do not wish to bring forward into the placement modeling system.<br>
<br>
Reasons the current functionality is poorly architected and buggy (mentioned in @melwitt's footnote):<br>
<br>
1) If a nova-compute service's CONF.cpu_allocation_ratio is different from the host aggregate's cpu_allocation_ratio metadata value, which value should be considered by the AggregateCoreFilter filter?<br>
<br>
2) If a nova-compute service is associated with multiple host aggregates, and those aggregates contain different values for their cpu_allocation_ratio metadata value, which one should be used by the AggregateCoreFilter?<br>
<br>
The bottom line for me is that the AggregateCoreFilter has been used as a crutch to solve a **configuration management problem**.<br>
<br>
Instead of the configuration management system (Puppet, etc) setting nova-compute service CONF.cpu_allocation_ratio options *correctly*, having the admin set the HostAggregate metadata cpu_allocation_ratio value is error-prone for the reasons listed above.<br>
<br></blockquote><div><br></div><div>Well, the main cause why people started to use AggregateCoreFilter and others is because pre-Newton, it was litterally impossible to assign different allocation ratios in between computes except if you were grouping them in aggregates and using those filters.</div><div>Now that ratios are per-compute, there is no need to keep those filters except if you don't touch computes nova.conf's so that it defaults to the scheduler ones. The crazy usecase would be like "I have 1000+ computes and I just want to apply specific ratios to only one or two" but then, I'd second Jay and say "Config management is the solution to your problem".</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Incidentally, this same design flaw is the reason that availability zones are so poorly defined in Nova. There is actually no such thing as an availability zone in Nova. Instead, an AZ is merely a metadata tag (or a CONF option! :( ) that may or may not exist against a host aggregate. There's lots of spaghetti in Nova due to the decision to use host aggregate metadata for availability zone information, which should have always been the domain of a **configuration management system** to set. [*]<br>
<br></blockquote><div><br></div><div>IMHO, not exactly the root cause why we have spaghetti code for AZs. I rather like the idea to see an availability zone as just a user-visible aggregate, because it makes things simple to understand.</div><div>What the spaghetti code is due to is because the transitive relationship between an aggregate, a compute and an instance is misunderstood and we introduced the notion of "instance AZ" which is a fool. Instances shouldn't have a field saying "here is my AZ", it should rather be a flag saying "what the user wanted as AZ ? (None being a choice) "</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the Placement service, we have the concept of aggregates, too. However, in Placement, an aggregate (note: not "host aggregate") is merely a grouping mechanism for resource providers. Placement aggregates do not have any attributes themselves -- they merely represent the relationship between resource providers. Placement aggregates suffer from neither of the above listed design flaws because they are not buckets for metadata.<br>
<br>
ok </rant>.<br>
<br>
Best,<br>
-jay<br>
<br>
[*] Note the assumption on line 97 here:<br>
<br>
<a href="https://github.com/openstack/nova/blob/master/nova/availability_zones.py#L96-L100" rel="noreferrer" target="_blank">https://github.com/openstack/n<wbr>ova/blob/master/nova/availabil<wbr>ity_zones.py#L96-L100</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
On Wed, Jan 17, 2018 at 5:24 AM, melanie witt <<a href="mailto:melwittt@gmail.com" target="_blank">melwittt@gmail.com</a> <mailto:<a href="mailto:melwittt@gmail.com" target="_blank">melwittt@gmail.com</a>>> wrote:<br>
<br>
    Hello Stackers,<br>
<br>
    This is a heads up to any of you using the AggregateCoreFilter,<br>
    AggregateRamFilter, and/or AggregateDiskFilter in the filter<br>
    scheduler. These filters have effectively allowed operators to set<br>
    overcommit ratios per aggregate rather than per compute node in <=<br>
    Newton.<br>
<br>
    Beginning in Ocata, there is a behavior change where aggregate-based<br>
    overcommit ratios will no longer be honored during scheduling.<br>
    Instead, overcommit values must be set on a per compute node basis<br>
    in nova.conf.<br>
<br>
    Details: as of Ocata, instead of considering all compute nodes at<br>
    the start of scheduler filtering, an optimization has been added to<br>
    query resource capacity from placement and prune the compute node<br>
    list with the result *before* any filters are applied. Placement<br>
    tracks resource capacity and usage and does *not* track aggregate<br>
    metadata [1]. Because of this, placement cannot consider<br>
    aggregate-based overcommit and will exclude compute nodes that do<br>
    not have capacity based on per compute node overcommit.<br>
<br>
    How to prepare: if you have been relying on per aggregate<br>
    overcommit, during your upgrade to Ocata, you must change to using<br>
    per compute node overcommit ratios in order for your scheduling<br>
    behavior to stay consistent. Otherwise, you may notice increased<br>
    NoValidHost scheduling failures as the aggregate-based overcommit is<br>
    no longer being considered. You can safely remove the<br>
    AggregateCoreFilter, AggregateRamFilter, and AggregateDiskFilter<br>
    from your enabled_filters and you do not need to replace them with<br>
    any other core/ram/disk filters. The placement query takes care of<br>
    the core/ram/disk filtering instead, so CoreFilter, RamFilter, and<br>
    DiskFilter are redundant.<br>
<br>
    Thanks,<br>
    -melanie<br>
<br>
    [1] Placement has been a new slate for resource management and prior<br>
    to placement, there were conflicts between the different methods for<br>
    setting overcommit ratios that were never addressed, such as, "which<br>
    value to take if a compute node has overcommit set AND the aggregate<br>
    has it set? Which takes precedence?" And, "if a compute node is in<br>
    more than one aggregate, which overcommit value should be taken?"<br>
    So, the ambiguities were not something that was desirable to bring<br>
    forward into placement.<br>
<br>
    ______________________________<wbr>______________________________<wbr>______________<br>
    OpenStack Development Mailing List (not for usage questions)<br>
    Unsubscribe:<br>
    <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br></div></div>
    <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
    <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><span class=""><br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>