Open Stack

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:

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.

Thanks
Ken Ohmichi