Le 04/12/2015 04:21, Alex Xu a écrit :
2015-12-02 23:12 GMT+08:00 Sylvain Bauza <sba...@redhat.com
<mailto: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.
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.
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://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
__________________________________________________________________________
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
