[openstack-dev] [nova] jsonschema for scheduler hints

Alex Xu soulxu at gmail.com
Fri Dec 4 03:21:37 UTC 2015

2015-12-02 23:12 GMT+08:00 Sylvain Bauza <sbauza at redhat.com>:

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

+1 also, and we should have capability API for discovering what hints
supported by current deployment.

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

There isn't any other Nova API return 401. So if you return 401, then
everybody will know that is the only 401 in the nova, so I think there
isn't any different. As we have capability API, it's fine let the user to
know what is supported in the deployment.

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

We can have code to check the out-of-tree filters didn't expose any same
hints with in-tree filter.

> -Sylvain
>         -Sean
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151204/2b05e5f1/attachment.html>

More information about the OpenStack-dev mailing list