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/core_filter.py> > * > https://review.openstack.org/#/c/37407/30/nova/scheduler/filters/io_ops_filter.py > *<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 > *<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