<div dir="ltr">
















<p class="MsoNormal">This option is useful in large deployments.<span></span></p>

<p class="MsoNormal">Our scheduler strategy is to "pack", however we are
not interested in this strategy per individual compute node but per sets of
them. One of the advantages is that when a user creates consecutive instances in the same AVZ it's
unlikely that they will be started in the same compute node. </p>

<p class="MsoNormal">Also, a problem in the "best" compute node doesn't
block completely the creation of new instances when not using
"retry".<span></span></p>

<p class="MsoNormal"><span> </span></p>

<p class="MsoNormal">Belmiro<span></span></p>

<p class="MsoNormal">--<span></span></p>

<p class="MsoNormal">CERN<span></span></p>

</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 7:17 PM, Edward Leafe <span dir="ltr"><<a href="mailto:ed@leafe.com" target="_blank">ed@leafe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[resending to include the operators list]<br>
<span class=""><br>
The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm would select the same host in both cases, leading to a race and a likely failure to build for the second request. By randomly choosing from the top N hosts, the likelihood of a race would be reduced, leading to fewer failed builds.<br>
<br>
Current changes in the scheduling process now have the scheduler claiming the resources as soon as it selects a host. So in the case above with 2 similar requests close together, the first request will claim successfully, but the second will fail *while still in the scheduler*. Upon failing the claim, the scheduler will simply pick the next host in its weighed list until it finds one that it can claim the resources from. So the host_subset_size configuration option is no longer needed.<br>
<br>
However, we have heard that some operators are relying on this option to help spread instances across their hosts, rather than using the RAM weigher. My question is: will removing this randomness from the scheduling process hurt any operators out there? Or can we safely remove that logic?<br>
<br>
<br>
-- Ed Leafe<br>
<br>
<br>
______________________________<wbr>_________________<br>
</span>OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</blockquote></div><br></div>