[openstack-dev] [Nova] support for multiple active scheduler policies/drivers
GLIKSON at il.ibm.com
Tue Jul 23 16:02:45 UTC 2013
Russell Bryant <rbryant at redhat.com> wrote on 23/07/2013 05:35:18 PM:
> >> #1 - policy associated with a host aggregate
> >> This seems very odd to me. Scheduling policy is what chooses hosts,
> >> having a subset of hosts specify which policy to use seems backwards.
> > 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
> Then I don't understand what this adds over the existing ability to
> specify an aggregate using extra_specs.
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
> >> #2 - via a scheduler hint
> >> How about just making the scheduling policy choice as simple as an
> >> in the flavor extra specs?
> > This is certainly an option. It would be just another implementation
> > the policy selection interface (implemented using filters). In fact,
> > already have it implemented -- just thought that explicit hint could
> > more straightforward to start with. Will include the implementation
> > based on flavor extra spec in the next commit.
> Ok. I'd actually prefer to remove the scheduler hint support
OK, removing the support for doing it via hint is easy :-)
> I'm not even sure it makes sense to make this pluggable. I
> can't think of why something other than flavor extra specs is necessary
> and justifies the additional complexity.
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
> I think some additional examples would help. It's also important to
> have this laid out for documentation purposes.
OK, sure, will add more. Hopefully few examples above are also helpful to
clarify the intention/design.
> Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev