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

Joe Gordon joe.gordon0 at gmail.com
Wed Aug 28 21:22:24 UTC 2013


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

> Joe Gordon <joe.gordon0 at gmail.com> wrote on 28/08/2013 11:04:45 PM:
>
> >> 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.
>
>
> Wouldn't it make sense to have a flag that enables/disables
> aggregate-based policy overrides anyway?
>

Why?

FWIW that is my default answer to don't we need a flag to do x.


>
> > 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.
>
> Yep, that's exactly what I'm saying -- the first step would be to put that
> logic in one place (e.g., scheduler/utils.py, like the get_config method we
> have been thinking to introduce originally), and then we can easily reuse
> it in all the other filters (regardless of the decision whether to do it
> within the existing filters, or to add an "AggregateXYZ" filter for each
> existing filter XYZ. Same potentially for weight functions, etc).
>

Sounds like we are in agreement here


>
> Alex
>
>
> _______________________________________________
> 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/fd2cb829/attachment.html>


More information about the OpenStack-dev mailing list