<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 28, 2013 at 3:55 PM, Alex Glikson <span dir="ltr"><<a href="mailto:GLIKSON@il.ibm.com" target="_blank">GLIKSON@il.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><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 face="sans-serif"><br>
</font>
<br></div><font 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></blockquote><div><br></div><div>* 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.</div>
<div><br></div><div>* <a href="https://github.com/openstack/nova/blob/master/nova/scheduler/filters/ram_filter.py">https://github.com/openstack/nova/blob/master/nova/scheduler/filters/ram_filter.py</a> 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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br><font face="sans-serif">Regards,</font>
<br><font 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 <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></font>
<br><div class="im"><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">OpenStack Development
Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, </font>
<br></div><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><div class=""><div class="h5">
<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" target="_blank"><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>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font><br>
</font></tt>
<br></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>