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. On Oct 9, 2015 10:12 AM, "Zane Bitter" <zbit...@redhat.com> wrote:
> On 08/10/15 21:32, Ian Wells wrote: > >> >> > 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 >> suitable hosts and that's a huge coincidence - so this is a tiny >> corner case that we shouldn't be designing around >> >> Here is where we differ in our understanding. With the current >> system of filters and weighers, 5 schedulers getting requests for >> identical VMs and having identical information are *expected* to >> select the same host. It is not a tiny corner case; it is the most >> likely result for the current system design. By catching this >> situation early (in the scheduling process) we can avoid multiple >> RPC round-trips to handle the fail/retry mechanism. >> >> >> And so maybe this would be a different fix - choose, at random, one of >> the hosts above a weighting threshold, not choose the top host every >> time? Technically, any host passing the filter is adequate to the task >> from the perspective of an API user (and they can't prove if they got >> the highest weighting or not), so if we assume weighting an operator >> preference, and just weaken it slightly, we'd have a few more options. >> > > 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.) > > 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. > > cheers, > Zane. > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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