Open Stack

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, 
so
> >> 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 
point.
> 
> 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 
corresponding aggregate.

> 
> >> #2 - via a scheduler hint
> >> How about just making the scheduling policy choice as simple as an 
item
> >> in the flavor extra specs?
> > 
> > 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.
> 
> Ok.  I'd actually prefer to remove the scheduler hint support
> completely. 

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 
considerations), etc

> 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.

Regards,
Alex

> -- 
> Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/b5042ee9/attachment.html>