[openstack-dev] [Nova] multiple-scheduler-drivers blueprint

Alex Glikson GLIKSON at il.ibm.com
Wed Aug 28 13:12:28 UTC 2013

It seems that the main concern was that the overridden scheduler 
properties are taken from the flavor, and not from the aggregate. In fact, 
there was a consensus that this is not optimal.

I think that we can still make some progress in Havana towards 
per-aggregate overrides, generalizing on the recently merged changes that 
do just that -- for cpu and for memory with FilterScheduler (and 
leveraging a bit from the original multi-sched patch). As follows:
1. individual filters will call get_config('abc') instead of CONF.abc 
(already implemented in the current version of the multi-sched patch, 
2. get_config() will check whether abc is defined in the aggregate, and if 
so will return the value from the aggregate, and CONF.abc otherwise 
(already implemented in recently merged AggregateCoreFilter and 
AggregateRamFilter -- e.g., 
3. add a global flag that would enable or disable aggregate-based 

This seems to be a relatively simple rafactoring of existing code, still 
achieving important portion of the original goals of this blueprint.
Of course, we should still discuss the longer-term plan around scheduling 
policies at the summit.



From:   Russell Bryant <rbryant at redhat.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Date:   27/08/2013 10:48 PM
Subject:        [openstack-dev] [Nova] multiple-scheduler-drivers 


One of the important things to strive for in our community is consensus.
 When there's not consensus, we should take a step back and see if we
need to change directions.

There has been a lot of iterating on this feature, and I'm afraid we
still don't have consensus around the design.  Phil Day has been posting
some really good feedback on the review.  I asked Joe Gordon to take a
look and provide another opinion.  He agreed with Phil that we really
need to have scheduler policies be a first class API citizen.

So, that pushes this feature out to Icehouse, as it doesn't seem
possible to get this done in the required timeframe for Havana.

If you'd really like to push to get this into Havana, please make your
case.  :-)


Russell Bryant

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130828/91260f33/attachment.html>

More information about the OpenStack-dev mailing list