[openstack-dev] [nova] jsonschema for scheduler hints

Andrew Laski andrew at lascii.com
Tue Dec 8 20:23:17 UTC 2015

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

>Ken Ohmichi
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list