Open Stack

Le 08/12/2015 21:23, Andrew Laski a écrit :
> On 12/06/15 at 02:49pm, Ken'ichi Ohmichi wrote:
>> Hi Sean,
>>
>> 2015-12-02 23:23 GMT+09:00 Sean Dague <sean at dague.net>:
>>> We have previously agreed that scheduler hints in Nova are an open 
>>> ended
>>> thing. It's expected for sites to have additional scheduler filters
>>> which expose new hints. The way we handle that with our strict
>>> jsonschema is that we allow additional properties -
>>> https://github.com/openstack/nova/blob/1734ce7101982dd95f8fab1ab4815bd258a33744/nova/api/openstack/compute/schemas/scheduler_hints.py#L65 
>>>
>>>
>>> This means that if you specify some garbage hint, you don't get 
>>> feedback
>>> that it was garbage in your environment. That lost a couple of days
>>> building multinode tests in the gate. Having gotten used to the hints
>>> that "you've given us bad stuff", this was a stark change back to the
>>> old world.
>>>
>>> Would it be possible to make it so that the schema could be explicitly
>>> extended (instead of implicitly extended). So that additional
>>> properties=False, but a mechanism for a scheduler filter to register
>>> it's jsonschema in?
>>
>> We had a prototype for registering scheduler_hints to jsonschema from
>> available filters:
>>
>> https://review.openstack.org/#/c/220440/
>>
>> That was against current basic design of nova and abandoned.
>> We need more time for finding right implementation way for that.
>>
>> BTW, I'd like to get feedback about scheduler_hints.
>> As the above jsonschema, nova just ignores unavailable scheduler_hint
>> if a client passes it.
>> So the client cannot know the specified scheduler_hint works or not
>> due to no feedback.
>> However, I feel that doesn't seem so bad because scheduler_hint is
>> just "hint" not "rule".
>> Nova can say "I consider this hint as possible, but sometimes ignore 
>> it".
>> In addition, Nova's purpose is for making physical environments 
>> abstract.
>> So it is not so bad to ignore the hint sometime.
>> Or should Nova handle scheduler_hint strictly?
>>
>> I guess that depends on use cases.
>> So if needing to handle scheduler_hint strictly, we need the above
>> kind of mechanism for registering available hints to jsonschema.
>
> Here's how it plays out in my mind:
>
> There's been a lot of work put into isolating the scheduler within 
> Nova, with a potential end goal of splitting it out.  With this in 
> mind there are a couple of options.  Scheduler filters that accept 
> hints could have an additional Nova component that adds in API schema 
> information.  This is not a desirable approach IMO.  Or the Nova API 
> could query the scheduler for a schema on startup and use that for 
> validation.  This keeps scheduling extensibility completely within the 
> scheduler.
>
> The second part of this is that the schema only really tells you that 
> you've used the correct hint name and format and nothing more.  There 
> is no feedback on if the hint was used, and its presence in the schema 
> does not mean the appropriate filter to use it is enabled.  Moving 
> towards having filters register hints when enabled would allow for the 
> schema to expose scheduling capabilities.  But that also means that 
> there's no guarantee that in in-tree hint like "same_host" would be 
> honored in every cloud. And right now no way to query the schema to 
> get the capabilities exposed.
>
> So the right path to me would be for the scheduler to be able to 
> construct a validation schema based on which filters are enabled, and 
> then expose an RPC(and later HTTP) interface for getting that schema.  
> Then nova-api could pull that schema at startup, and have a mechanism 
> to re-acquire and load it.
>

I'm fine with a new RPC call for getting the schema, but as I explained, 
I think the schema should be accepting all the in-tree filter hints (ie. 
nova.scheduler.filters.all_filters method), not only those which are 
enabled (ie. scheduler_default_filters conf opt). Not sure if that's 
also what you said, I could have been misunderstanding.

Also, I'm not opiniated about out-of-tree filters. We could just provide 
the schema for scheduler_enabled_filters conf opt which would then 
accept custom hints, but I wonder if it would get an interop problem 
like I said.

-Sylvain


>>
>> Thanks
>> Ken Ohmichi
>>
>> __________________________________________________________________________ 
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________ 
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev