2015-12-04 16:48 GMT+08:00 Sylvain Bauza <sba...@redhat.com>: > > > Le 04/12/2015 04:21, Alex Xu a écrit : > > > > 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. > > > > Sorry, I made a mistake by providing a wrong HTTP code for when the > validation returns a ValidationError (due to the JSON schema not matched by > the request). > Here, my point is that if we enforce a per-enabled-filter basis for > checking whether the hint should be enforced, it would mean that as an > hacker, I could have some way to know what filters are enabled, or as an > user, I could have different behaviours depending on the deployment. > > Let me give you an example: say that I'm not enabling the SameHostFilter > which exposes the 'same_host' hint. > > For that specific cloud, if we allow to deny a request which could provide > the 'same-host' hint (because the filter is not loaded by the > 'scheduler_default_filters' option), it would make a difference with > another cloud which enables SameHostFilter (because the request would pass). > > So, I'm maybe nitpicking, but I want to make clear that we shouldn't > introspect the state of the filter, and just consider a static JSON schema > (as we have today) which would reference all the hints, whether the > corresponding filter is enabled or not. >
yes, I see your concern, that is why I think we should have capabilities API. User should query the capabilities API to ensure what filter enabled in the current cloud. > > > > > >> 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. > > > > Sure, and thank you for that, that was missing in the past. That said, > there are still some interoperability concerns, let me explain : as a cloud > operator, I'm now providing a custom filter (say MyAwesomeFilter) which > does the lookup for an hint called 'my_awesome_hint'. > > If we enforce a strict validation (and not allow to accept any hint) it > would mean that this cloud would accept a request with 'my_awesome_hint' > while another cloud which wouldn't be running MyAwesomeFilter would then > deny the same request. > yes, same answer as above, capabilities API is used to discover enabled 'hints'. > > Hope I better explained my concerns, > -Sylvain > > >> >> -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:unsubscribehttp://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 > >
__________________________________________________________________________ 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