[openstack-dev] [nova] jsonschema for scheduler hints
sbauza at redhat.com
Wed Dec 2 15:12:37 UTC 2015
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 -
> 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
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.
More information about the OpenStack-dev