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
__________________________________________________________________________
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
