Open Stack

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 <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.
>>
>>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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev