<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-12-02 23:12 GMT+08:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
Le 02/12/2015 15:23, Sean Dague a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We have previously agreed that scheduler hints in Nova are an open ended<br>
thing. It's expected for sites to have additional scheduler filters<br>
which expose new hints. The way we handle that with our strict<br>
jsonschema is that we allow additional properties -<br>
<a href="https://github.com/openstack/nova/blob/1734ce7101982dd95f8fab1ab4815bd258a33744/nova/api/openstack/compute/schemas/scheduler_hints.py#L65" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/1734ce7101982dd95f8fab1ab4815bd258a33744/nova/api/openstack/compute/schemas/scheduler_hints.py#L65</a><br>
<br>
This means that if you specify some garbage hint, you don't get feedback<br>
that it was garbage in your environment. That lost a couple of days<br>
building multinode tests in the gate. Having gotten used to the hints<br>
that "you've given us bad stuff", this was a stark change back to the<br>
old world.<br>
<br>
Would it be possible to make it so that the schema could be explicitly<br>
extended (instead of implicitly extended). So that additional<br>
properties=False, but a mechanism for a scheduler filter to register<br>
it's jsonschema in?<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>+1 also, and we should have capability API for discovering what hints supported by current deployment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.*<br>
<br>
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.<br>
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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>We can have code to check the out-of-tree filters didn't expose any same hints with in-tree filter.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
-Sylvain<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        -Sean<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>