2015-12-02 23:12 GMT+08:00 Sylvain Bauza <sba...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
