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 <[email protected]>:
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:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
