Open Stack

> Why can't something like this be done with just different filters, see 
such as for AggregateRamFilter?

Well, first, at the moment each of these filters today duplicate the code 
that handles aggregate-based overrides. So, it would make sense to have it 
in one place anyway. Second, why duplicating all the filters if this can 
be done with a single flag? 

Regards,
Alex




From:   Joe Gordon <joe.gordon0 at gmail.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Date:   28/08/2013 09:32 PM
Subject:        Re: [openstack-dev] [Nova] multiple-scheduler-drivers 
blueprint






On Wed, Aug 28, 2013 at 9:12 AM, Alex Glikson <GLIKSON at il.ibm.com> wrote:
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, 
e.g., 
https://review.openstack.org/#/c/37407/30/nova/scheduler/filters/io_ops_filter.py
) 
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., 
https://review.openstack.org/#/c/33949/2/nova/scheduler/filters/core_filter.py
). 
3. add a global flag that would enable or disable aggregate-based 
overrides 

Why can't something like this be done with just different filters, see 
such as for AggregateRamFilter?
 

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. 

Thoughts? 

Regards, 
Alex 




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 
blueprint 




Greetings,

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.  :-)

Thanks,

-- 
Russell Bryant

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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