[openstack-dev] [nova] jsonschema for scheduler hints
sbauza at redhat.com
Tue Dec 8 20:43:35 UTC 2015
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
>>> 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 -
>>> This means that if you specify some garbage hint, you don't get
>>> 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
>> In addition, Nova's purpose is for making physical environments
>> 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
> 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.
>> Ken Ohmichi
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev