<tt><font size=2>Russell Bryant <rbryant@redhat.com> wrote on 23/07/2013
05:35:18 PM:<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>
> > This is not what we had in mind. Host aggregate is selected based
on<br>
> > policy passed in the request (hint, extra spec, or whatever --
see<br>
> > below) and 'policy' attribute of the aggregate -- possibly in<br>
> > conjunction with 'regular' aggregate filtering. And not the other
way<br>
> > around. Maybe the design document is not clear enough about this
point.<br>
> <br>
> Then I don't understand what this adds over the existing ability to<br>
> specify an aggregate using extra_specs.</font></tt>
<br>
<br><tt><font size=2>The added value is in the ability to configure the
scheduler accordingly -- potentially differently for different aggregates
-- in addition to just restricting the target host to those belonging to
an aggregate with certain properties. For example, let's say we want to
support two classes of workloads - CPU-intensive, and memory-intensive.
The administrator may decide to use 2 different hardware models, and configure
one aggregate with lots of CPU, and another aggregate with lots of memory.
In addition to just routing an incoming provisioning request to the correct
aggregate (which can be done already), we may want different cpu_allocation_ratio
and memory_allocation_ratio when managing resources in each of the aggregates.
In order to support this, we would define 2 policies (with corresponding
configuration of filters), and attach each one to the corresponding aggregate.</font></tt>
<br><tt><font size=2><br>
> <br>
> >> #2 - via a scheduler hint<br>
> >> How about just making the scheduling policy choice as simple
as an item<br>
> >> in the flavor extra specs?<br>
> > <br>
> > This is certainly an option. It would be just another implementation
of<br>
> > the policy selection interface (implemented using filters). In
fact, we<br>
> > already have it implemented -- just thought that explicit hint
could be<br>
> > more straightforward to start with. Will include the implementation<br>
> > based on flavor extra spec in the next commit.<br>
> <br>
> Ok.  I'd actually prefer to remove the scheduler hint support<br>
> completely. </font></tt>
<br>
<br><tt><font size=2>OK, removing the support for doing it via hint is
easy :-)</font></tt>
<br>
<br><tt><font size=2>> I'm not even sure it makes sense to make this
pluggable.  I<br>
> can't think of why something other than flavor extra specs is necessary<br>
> and justifies the additional complexity.</font></tt>
<br>
<br><tt><font size=2>Well, I can think of few use-cases when the selection
approach might be different. For example, it could be based on tenant properties
(derived from some kind of SLA associated with the tenant, determining
the over-commit levels), or image properties (e.g., I want to determine
placement of Windows instances taking into account Windows licensing considerations),
etc</font></tt>
<br><tt><font size=2><br>
> I think some additional examples would help.  It's also important
to<br>
> have this laid out for documentation purposes.</font></tt>
<br>
<br><tt><font size=2>OK, sure, will add more. Hopefully few examples above
are also helpful to clarify the intention/design.</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>
</font></tt>