On 12/06/15 at 02:49pm, Ken'ichi Ohmichi wrote:
Hi Sean,
2015-12-02 23:23 GMT+09:00 Sean Dague <s...@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.
Thanks
Ken Ohmichi
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
