<tt><font size=2>Russell Bryant <rbryant@redhat.com> wrote on 23/07/2013
01:04:24 AM:<br>
> > [1] </font></tt><a href="https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers"><tt><font size=2>https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers</font></tt></a><tt><font size=2><br>
> > [2] </font></tt><a href=https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies><tt><font size=2>https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies</font></tt></a><tt><font size=2><br>
> > [3] </font></tt><a href=https://review.openstack.org/#/c/37407/><tt><font size=2>https://review.openstack.org/#/c/37407/</font></tt></a><tt><font size=2><br>
> <br>
> Thanks for bringing this up.  I do have some comments.</font></tt>
<br>
<br><tt><font size=2>Thanks for the comments. See below.</font></tt>
<br><tt><font size=2><br>
> <br>
> The current design shows 2 different use cases for how a scheduling<br>
> policy would be chosen.</font></tt>
<br><tt><font size=2>> <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.</font></tt>
<br>
<br><tt><font size=2>This is not what we had in mind. Host aggregate is
selected based on policy passed in the request (hint, extra spec, or whatever
-- see below) and 'policy' attribute of the aggregate -- possibly in conjunction
with 'regular' aggregate filtering. And not the other way around. Maybe
the design document is not clear enough about this point.</font></tt>
<br><tt><font size=2><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?</font></tt>
<br>
<br><tt><font size=2>This is certainly an option. It would be just another
implementation of the policy selection interface (implemented using filters).
In fact, we already have it implemented -- just thought that explicit hint
could be more straightforward to start with. Will include the implementation
based on flavor extra spec in the next commit.</font></tt>
<br><tt><font size=2><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.</font></tt>
<br>
<br><tt><font size=2>This is certainly supported. Just didn't want to complicate
the example too much. It could be even a different driver, assuming that
the driver complies with the 'policy' attribute of the aggregates -- which
is achieved by PolicyFilter in FilterScheduler. We plan to make other drivers
'policy-aware' in a future patch, leveraging the new db method that returns
hosts belonging to aggregates with compatible policies.</font></tt>
<br>
<br><tt><font size=2>Hope this clarifies the concerns.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Alex</font></tt>
<br><tt><font size=2><br>
> -- <br>
> Russell Bryant<br>
> <br>
</font></tt>