Open Stack

Phil,

I agree with the suggestion. We wanted to instantiate a set of VMs whose hosts are located close each other. The current scheduler could not handle this use case since it needed to return "optimal" set of hosts at the same time. The first "optimal" host returned by the current scheduler may not be a part of the set of "optimal" hosts. We worked on the scheduler a little (in draft mode), and if you are interested in it, please let me know.

Thanks,

Joseph

----- Original Message -----
From: "Vishvananda Ishaya" <vishvananda at gmail.com>
To: "Phil Day" <philip.day at hp.com>
Cc: "openstack at lists.launchpad.net (openstack at lists.launchpad.net) (openstack at lists.launchpad.net)" <openstack at lists.launchpad.net>
Sent: Thursday, January 3, 2013 12:43:02 PM
Subject: Re: [Openstack] Potential filter scheduler enhancement


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.day at 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 at lists.launchpad.net 
Unsubscribe : https://launchpad.net/~openstack 
More help : https://help.launchpad.net/ListHelp 


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp