> 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.gord...@gmail.com> To: OpenStack Development Mailing List <openstack-dev@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 <glik...@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 <rbry...@redhat.com> To: OpenStack Development Mailing List < openstack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev