openstack team mailing list archive

["Day, Phil" <philip.day@xxxxxx>]

Hi Folks, and Happy New Year.

In working with the Filter Scheduler I'm considering an enhancement to make the final host selection stage configurable.  Whilst its sometimes fine to just pick the first host from the list of weighted hosts, the more general case is that I'd like to be able to have the scheduler pick one of the first N hosts on the weighted list.    The specific use cases that I have in mind are:


-          On a large system there is very rarely a single ideal / optimal host for a particular instance to be placed on.  In practice any of the N most suitable hosts would be fine and allowing the scheduler to randomly pick one of these would add some spread for multiple requests that come in at the same time.  (I know we now have the retry mechanism if a particular host can't in fact handle a specific request - this is a complement to that rather an alternative).      Of course anyone who wants to schedule to host in strict weighted order would be able to configure N to be 1 (or we could keep the current host selection method as a separate default)


-          When creating M instances in one request we could just put each onto one of the first M hosts in the list (since these have all been filtered as being suitable) instead of having to iterate through the filter / weighting functions for each successive instance.

Based on this I'm thinking that such a host_selection function would replace the whole of the for loop at the end of the _schedule() method in filter_scheduler.py, and take as input the number of instances.  The default function would of course be the current behaviour.     Before going any further with this thinking I wanted to get input on:


i)                    Do others recognise these use cases as being useful, and are there other similar use cases to be considered at the same time ?



ii)                   Is it reasonable to make the filter scheduler configurable in this way, rather than creating a separate scheduler ?   (My feeling  is that because it would only be replacing ~10% of the current filter_scheduler code it would be better to not create a new scheduler)



iii)                 Should the configuration logic for this new function be in the fliter_scheduler itself, or in the host_manager (which is where the filter and weighting functions are configured) ?


Cheers,
Phil