Open Stack

On Wed, Aug 28, 2013 at 3:55 PM, Alex Glikson <GLIKSON at il.ibm.com> wrote:

> > 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?


* We already have too many flags, and i don't want to introduce one that we
plan on removing / deprecating in the near future if we can help it.

*
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/ram_filter.py
doesn't
duplicate all the code, it uses a base class.  The check the aggregate for
the value logic is duplicated, but that is easy to fix.


>
>
> 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*<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/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 <*rbryant at redhat.com* <rbryant at redhat.com>>
> To:        OpenStack Development Mailing List <*
> openstack-dev at lists.openstack.org* <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* <OpenStack-dev at lists.openstack.org>*
> **http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list*
> **OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>*
> **http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<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/ead8d337/attachment.html>