[openstack-dev] Scheduler proposal

Gregory Haynes greg at greghaynes.net
Fri Oct 9 21:00:05 UTC 2015

Excerpts from Chris Friesen's message of 2015-10-09 19:36:03 +0000:
> On 10/09/2015 12:55 PM, Gregory Haynes wrote:
> > There is a more generalized version of this algorithm for concurrent
> > scheduling I've seen a few times - Pick N options at random, apply
> > heuristic over that N to pick the best, attempt to schedule at your
> > choice, retry on failure. As long as you have a fast heuristic and your
> > N is sufficiently smaller than the total number of options then the
> > retries are rare-ish and cheap. It also can scale out extremely well.
> If you're looking for a resource that is relatively rare (say you want a 
> particular hardware accelerator, or a very large number of CPUs, or even to be 
> scheduled "near" to a specific other instance) then you may have to retry quite 
> a lot.
> Chris

Yep. You can either be fast or correct. There is no solution which will
both scale easily and allow you to schedule to a very precise node
efficiently or this would be a solved problem.

There is a not too bad middle ground here though - you can definitely do
some filtering beforehand efficiently (especially if you have some kind
of local cache similar to what Josh mentioned with ZK) and then this is
less of an issue. This is definitely a big step in complexity though...


More information about the OpenStack-dev mailing list