<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-12-04 16:48 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div>Le 04/12/2015 04:21, Alex Xu a écrit :<br>
</div>
<blockquote type="cite">
<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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
<br>
Le 02/12/2015 15:23, Sean Dague a écrit :<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>
</div>
</div>
</div>
</blockquote>
<br></span>
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).<br>
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.<br>
<br>
Let me give you an example: say that I'm not enabling the
SameHostFilter which exposes the 'same_host' hint.<br>
<br>
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).<br>
<br>
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.</div></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>
</div>
</div>
</div>
</blockquote>
<br></span>
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'.<br>
<br>
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.<br></div></blockquote><div><br></div><div>yes, same answer as above, capabilities API is used to discover enabled 'hints'.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Hope I better explained my concerns,<br>
-Sylvain<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
-Sylvain<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
-Sean<br>
<br>
</blockquote>
<div>
<div>
<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>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</span></div>
<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>
<br></blockquote></div><br></div></div>