Open Stack

On 07/23/2013 12:24 AM, Alex Glikson wrote:
> Russell Bryant <rbryant at redhat.com> wrote on 23/07/2013 01:04:24 AM:
>> > [1]
> https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers
>> > [2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies
>> > [3] https://review.openstack.org/#/c/37407/
>>
>> Thanks for bringing this up.  I do have some comments.
> 
> Thanks for the comments. See below.
> 
>>
>> The current design shows 2 different use cases for how a scheduling
>> policy would be chosen.
>>
>> #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.

>> #2 - via a scheduler hint
>>
>> It also seems odd to have the user specifying scheduling policy.  This
>> seems like something that should be completely hidden from the user.
>>
>> 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.  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.

>> The design also shows some example configuration.  It shows a global set
>> of enabled scheduler filters, and then policy specific tweaks of filter
>> config (CPU allocation ratio in the example).  I would expect to be able
>> to set a scheduling policy specific list of scheduler filters and
>> weights, as well.
> 
> 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.

I think some additional examples would help.  It's also important to
have this laid out for documentation purposes.

-- 
Russell Bryant