Open Stack

On 07/23/2013 12:02 PM, Alex Glikson wrote:
> 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.

I understand the use case, but can't it just be achieved with 2 flavors
and without this new aggreagte-policy mapping?

flavor 1 with extra specs to say aggregate A and policy Y
flavor 2 with extra specs to say aggregate B and policy Z

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

Well, you can define tenant specific flavors that could have different
policy configurations.

I think I'd rather hold off on the extra complexity until there is a
concrete implementation of something that requires and justifies it.

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