<font size=3>> Why can't something like this be done with just different
filters, see such as for AggregateRamFilter</font><font size=1 color=#40005f face="Lucida Console"><b>?</b></font><font size=2 face="sans-serif"><br>
</font>
<br><font size=2 face="sans-serif">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? </font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Joe Gordon <joe.gordon0@gmail.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">28/08/2013 09:32 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[Nova] multiple-scheduler-drivers blueprint</font>
<br>
<hr noshade>
<br>
<br>
<br>
<br><font size=3><br>
</font>
<br><font size=3>On Wed, Aug 28, 2013 at 9:12 AM, Alex Glikson <</font><a href=mailto:GLIKSON@il.ibm.com target=_blank><font size=3 color=blue><u>GLIKSON@il.ibm.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3 face="sans-serif">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.</font><font size=3>
<br>
</font><font size=3 face="sans-serif"><br>
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:</font><font size=3> </font><font size=3 face="sans-serif"><br>
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., </font><a href=https://review.openstack.org/#/c/37407/30/nova/scheduler/filters/core_filter.py target=_blank></a><a href=https://review.openstack.org/#/c/37407/30/nova/scheduler/filters/io_ops_filter.py target=_blank><font size=3 color=blue><u>https://review.openstack.org/#/c/37407/30/nova/scheduler/filters/io_ops_filter.py</u></font></a><font size=3 face="sans-serif">)</font><font size=3>
</font><font size=3 face="sans-serif"><br>
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., </font><a href=https://review.openstack.org/#/c/33949/2/nova/scheduler/filters/core_filter.py target=_blank><font size=3 color=blue><u>https://review.openstack.org/#/c/33949/2/nova/scheduler/filters/core_filter.py</u></font></a><font size=3 face="sans-serif">).</font><font size=3>
</font><font size=3 face="sans-serif"><br>
3. add a global flag that would enable or disable aggregate-based overrides</font><font size=3>
</font>
<br>
<br><font size=3>Why can't something like this be done with just different
filters, see such as for AggregateRamFilter</font><font size=1 color=#40005f face="Lucida Console"><b>?</b></font>
<br><font size=3> </font>
<br><font size=3 face="sans-serif"><br>
This seems to be a relatively simple rafactoring of existing code, still
achieving important portion of the original goals of this blueprint.</font><font size=3>
</font><font size=3 face="sans-serif"><br>
Of course, we should still discuss the longer-term plan around scheduling
policies at the summit.</font><font size=3> <br>
</font><font size=3 face="sans-serif"><br>
Thoughts?</font><font size=3> <br>
</font><font size=3 face="sans-serif"><br>
Regards,</font><font size=3> </font><font size=3 face="sans-serif"><br>
Alex</font><font size=3> <br>
<br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From: </font><font size=1 face="sans-serif">Russell
Bryant <</font><a href=mailto:rbryant@redhat.com target=_blank><font size=1 color=blue face="sans-serif"><u>rbryant@redhat.com</u></font></a><font size=1 face="sans-serif">></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">OpenStack
Development Mailing List <</font><a href="mailto:openstack-dev@lists.openstack.org" target=_blank><font size=1 color=blue face="sans-serif"><u>openstack-dev@lists.openstack.org</u></font></a><font size=1 face="sans-serif">>,
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">27/08/2013
10:48 PM</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">[openstack-dev]
[Nova] multiple-scheduler-drivers blueprint</font><font size=3> <br>
</font>
<hr noshade>
<br><font size=3><br>
<br>
</font><tt><font size=3><br>
Greetings,<br>
<br>
One of the important things to strive for in our community is consensus.<br>
When there's not consensus, we should take a step back and see if we<br>
need to change directions.<br>
<br>
There has been a lot of iterating on this feature, and I'm afraid we<br>
still don't have consensus around the design. Phil Day has been posting<br>
some really good feedback on the review. I asked Joe Gordon to take
a<br>
look and provide another opinion. He agreed with Phil that we really<br>
need to have scheduler policies be a first class API citizen.<br>
<br>
So, that pushes this feature out to Icehouse, as it doesn't seem<br>
possible to get this done in the required timeframe for Havana.<br>
<br>
If you'd really like to push to get this into Havana, please make your<br>
case. :-)<br>
<br>
Thanks,<br>
<br>
-- <br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list</font></tt><tt><font size=3 color=blue><u><br>
</u></font></tt><a href="mailto:OpenStack-dev@lists.openstack.org" target=_blank><tt><font size=3 color=blue><u>OpenStack-dev@lists.openstack.org</u></font></tt></a><font size=3 color=blue><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target=_blank><tt><font size=3 color=blue><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></tt></a><tt><font size=3><br>
</font></tt><font size=3><br>
</font>
<br><font size=3><br>
_______________________________________________<br>
OpenStack-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org"><font size=3 color=blue><u>OpenStack-dev@lists.openstack.org</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target=_blank><font size=3 color=blue><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size=3><br>
</font>
<br><tt><font size=2>_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>