I think this seems reasonable, although FYI, openstack-dev seems like a better place for emails like this.
Vish On Jan 3, 2013, at 6:40 AM, "Day, Phil" <philip....@hp.com> wrote: > 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 > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
