<p dir="ltr">I have a quick question: how is Amazon doing this? When choosing a next path forward that reliably scales, would be interesting to know how this is already being done.</p>
<div class="gmail_quote">On Oct 9, 2015 10:12 AM, "Zane Bitter" <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/10/15 21:32, Ian Wells wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    > 2. if many hosts suit the 5 VMs then this is *very* unlucky,because we should be choosing a host at random from the set of<br>
    suitable hosts and that's a huge coincidence - so this is a tiny<br>
    corner case that we shouldn't be designing around<br>
<br>
    Here is where we differ in our understanding. With the current<br>
    system of filters and weighers, 5 schedulers getting requests for<br>
    identical VMs and having identical information are *expected* to<br>
    select the same host. It is not a tiny corner case; it is the most<br>
    likely result for the current system design. By catching this<br>
    situation early (in the scheduling process) we can avoid multiple<br>
    RPC round-trips to handle the fail/retry mechanism.<br>
<br>
<br>
And so maybe this would be a different fix - choose, at random, one of<br>
the hosts above a weighting threshold, not choose the top host every<br>
time? Technically, any host passing the filter is adequate to the task<br>
from the perspective of an API user (and they can't prove if they got<br>
the highest weighting or not), so if we assume weighting an operator<br>
preference, and just weaken it slightly, we'd have a few more options.<br>
</blockquote>
<br>
The optimal way to do this would be a weighted random selection, where the probability of any given host being selected is proportional to its weighting. (Obviously this is limited by the accuracy of the weighting function in expressing your actual preferences - and it's at least conceivable that this could vary with the number of schedulers running.)<br>
<br>
In fact, the choice of the name 'weighting' would normally imply that it's done this way; hearing that the 'weighting' is actually used as a 'score' with the highest one always winning is quite surprising.<br>
<br>
cheers,<br>
Zane.<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>