Open Stack

This option is useful in large deployments.

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.

Also, a problem in the "best" compute node doesn't block completely the
creation of new instances when not using "retry".



Belmiro

--

CERN

On Fri, May 26, 2017 at 7:17 PM, Edward Leafe <ed at leafe.com> wrote:

> [resending to include the operators list]
>
> 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.
>
> 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.
>
> 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?
>
>
> -- Ed Leafe
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170528/93fa6fd9/attachment.html>