On 12/08/15 at 09:43pm, Sylvain Bauza wrote:
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 <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.
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.
I really didn't take a stance there, though I was leading towards only
exposing hints for enabled filters because it moves towards exposing
scheduling capabilities. But just because it could be done that way
doesn't mean it should be. The validation schema and eventual exposure
of capabilities could be done through two different mechanisms.
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-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
__________________________________________________________________________
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
