<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 28, 2013 at 9:12 AM, 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"><font 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>
<br>
<br><font face="sans-serif">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>
<br><font face="sans-serif">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 face="sans-serif">)</font>
<br><font face="sans-serif">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 face="sans-serif">).</font>
<br><font face="sans-serif">3. add a global flag that would enable
or disable aggregate-based overrides</font>
<br></blockquote><div><br></div><div>Why can't something like this be done with just different filters, see such as for AggregateRamFilter<span style="color:rgb(68,0,68);font-family:'Lucida Console','Lucida Sans Typewriter',Monaco,monospace;font-size:11.111111640930176px;font-weight:bold;white-space:pre">?</span></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><font face="sans-serif">This seems to be a relatively simple
rafactoring of existing code, still achieving important portion of the
original goals of this blueprint.</font>
<br><font face="sans-serif">Of course, we should still discuss the
longer-term plan around scheduling policies at the summit.</font>
<br>
<br><font face="sans-serif">Thoughts?</font>
<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">Russell Bryant <<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></font>
<br><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><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">27/08/2013 10:48 PM</font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">[openstack-dev]
[Nova] multiple-scheduler-drivers blueprint</font>
<br>
<hr noshade><div class=""><div class="h5">
<br>
<br>
<br><tt><font>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<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>
<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>