Open Stack

Le 02/12/2015 15:23, Sean Dague a écrit :
> 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?

I'm pretty +1 for that because we want to have in-tree filters clear for 
the UX they provide when asking for scheduler hints.

For the moment, it's possible to have 2 different filters asking for the 
same hint without providing a way to explain the semantics so I would 
want to make sure that one in-tree filter could just have the same 
behaviour for *all the OpenStack deployments.*

That said, I remember some discussion we had about that in the past, and 
the implementation details we discussed about having the Nova API 
knowing the list of filters and fitering by those.
To be clear, I want to make sure that we could not leak the deployment 
by providing a 401 if a filter is not deployed, but rather just make 
sure that all our in-tree filters are like checked, even if they aren't 
deployed.

That leaves the out-of-tree discussion about custom filters and how we 
could have a consistent behaviour given that. Should we accept something 
in a specific deployment while another deployment could 401 against it ? 
Mmm, bad to me IMHO.


-Sylvain

> 	-Sean
>