<div dir="ltr"><div>That only means after 599276 we only have servers API and os-instance-action API stopped accepting the undefined query parameter.</div><div><br></div><div>What I'm thinking about is checking all the APIs, add json-query-param checking with additionalProperties=True if the API don't have yet. And using another microversion set additionalProperties to False, then the whole Nova API become consistent.</div><br><div class="gmail_quote"><div dir="ltr">Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> 于2018年9月18日周二 上午4:07写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/17/2018 03:28 PM, Matt Riedemann wrote:<br>
> This is a question from a change [1] which adds a new changes-before <br>
> filter to the servers, os-instance-actions and os-migrations APIs.<br>
> <br>
> For context, the os-instance-actions API stopped accepting undefined <br>
> query parameters in 2.58 when we added paging support.<br>
> <br>
> The os-migrations API stopped allowing undefined query parameters in <br>
> 2.59 when we added paging support.<br>
> <br>
> The open question on the review is if we should change GET /servers and <br>
> GET /servers/detail to stop allowing undefined query parameters starting <br>
> with microversion 2.66 [2]. Apparently when we added support for 2.5 and <br>
> 2.26 for listing servers we didn't think about this. It means that a <br>
> user can specify a query parameter, documented in the API reference, but <br>
> with an older microversion and it will be silently ignored. That is <br>
> backward compatible but confusing from an end user perspective since it <br>
> would appear to them that the filter is not being applied, when it fact <br>
> it would be if they used the correct microversion.<br>
> <br>
> So do we want to start enforcing query parameters when listing servers <br>
> to our defined list with microversion 2.66 or just continue to silently <br>
> ignore them if used incorrectly?<br>
> <br>
> Note that starting in Rocky, the Neutron API will start rejecting <br>
> unknown query parameteres [3] if the filter-validation extension is <br>
> enabled (since Neutron doesn't use microversions). So there is some <br>
> precedent in OpenStack for starting to enforce query parameters.<br>
> <br>
> [1] <a href="https://review.openstack.org/#/c/599276/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/599276/</a><br>
> [2] <br>
> <a href="https://review.openstack.org/#/c/599276/23/nova/api/openstack/compute/schemas/servers.py" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/599276/23/nova/api/openstack/compute/schemas/servers.py</a> <br>
> <br>
> [3] <br>
> <a href="https://docs.openstack.org/releasenotes/neutron/rocky.html#upgrade-notes" rel="noreferrer" target="_blank">https://docs.openstack.org/releasenotes/neutron/rocky.html#upgrade-notes</a><br>
<br>
My vote would be just change additionalProperties to False in the 599276 <br>
patch and be done with it.<br>
<br>
Add a release note about the change, of course.<br>
<br>
-jay<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>
</blockquote></div></div>