<font size=2 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 size=2 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 size=2 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><a href=https://review.openstack.org/#/c/37407/30/nova/scheduler/filters/io_ops_filter.py><font size=3 color=blue><u>https://review.openstack.org/#/c/37407/30/nova/scheduler/filters/io_ops_filter.py</u></font></a></a><font size=2 face="sans-serif">)</font>
<br><font size=2 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><font size=3 color=blue><u>https://review.openstack.org/#/c/33949/2/nova/scheduler/filters/core_filter.py</u></font></a><font size=2 face="sans-serif">).</font>
<br><font size=2 face="sans-serif">3. add a global flag that would enable
or disable aggregate-based overrides</font>
<br>
<br><font size=2 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 size=2 face="sans-serif">Of course, we should still discuss the
longer-term plan around scheduling policies at the summit.</font>
<br>
<br><font size=2 face="sans-serif">Thoughts?</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">Russell Bryant <rbryant@redhat.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">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>
<br>
<br>
<br><tt><font size=2>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>
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>
<br>
</font></tt>
<br>