<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 3:04 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/22/2013 05:15 PM, Alex Glikson wrote:<br>
> Dear all,<br>
><br>
> Following the initial discussions at the last design summit, we have<br>
> published the design [2] and the first take on the implementation [3] of<br>
> the blueprint adding support for multiple active scheduler<br>
> policies/drivers [1].<br>
> In a nutshell, the idea is to allow overriding the 'default' scheduler<br>
> configuration parameters (driver, filters, their configuration<br>
> parameters, etc) for particular host aggregates. The 'policies' are<br>
> introduced as sections in nova.conf, and each host aggregate can have a<br>
> key-value specifying the policy (by name).<br>
><br>
> Comments on design or implementation are welcome!<br>
><br>
> Thanks,<br>
> Alex<br>
><br>
><br>
> [1] <a href="https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers" target="_blank">https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers</a><br>
> [2] <a href="https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies" target="_blank">https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies</a><br>
> [3] <a href="https://review.openstack.org/#/c/37407/" target="_blank">https://review.openstack.org/#/c/37407/</a><br>
<br>
</div></div>Thanks for bringing this up.  I do have some comments.<br>
<br>
The current design shows 2 different use cases for how a scheduling<br>
policy would be chosen.<br>
<br>
#1 - policy associated with a host aggregate<br>
<br>
This seems very odd to me.  Scheduling policy is what chooses hosts, so<br>
having a subset of hosts specify which policy to use seems backwards.<br>
<br>
#2 - via a scheduler hint<br>
<br>
It also seems odd to have the user specifying scheduling policy.  This<br>
seems like something that should be completely hidden from the user.<br>
<br>
How about just making the scheduling policy choice as simple as an item<br>
in the flavor extra specs?<br></blockquote><div><br></div><div>++, IMHO we already reveal too much scheduling information to the user via are current set of scheduler hints.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
The design also shows some example configuration.  It shows a global set<br>
of enabled scheduler filters, and then policy specific tweaks of filter<br>
config (CPU allocation ratio in the example).  I would expect to be able<br>
to set a scheduling policy specific list of scheduler filters and<br>
weights, as well.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
<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>
</font></span></blockquote></div><br></div></div>