Open Stack

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

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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-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/75278343/attachment.html>