[openstack-dev] [nova] When can/should we change additionalProperties=False in GET /servers(/detail)?
Jay Pipes
jaypipes at gmail.com
Mon Sep 17 20:06:43 UTC 2018
On 09/17/2018 03:28 PM, Matt Riedemann wrote:
> This is a question from a change [1] which adds a new changes-before
> filter to the servers, os-instance-actions and os-migrations APIs.
>
> For context, the os-instance-actions API stopped accepting undefined
> query parameters in 2.58 when we added paging support.
>
> The os-migrations API stopped allowing undefined query parameters in
> 2.59 when we added paging support.
>
> The open question on the review is if we should change GET /servers and
> GET /servers/detail to stop allowing undefined query parameters starting
> with microversion 2.66 [2]. Apparently when we added support for 2.5 and
> 2.26 for listing servers we didn't think about this. It means that a
> user can specify a query parameter, documented in the API reference, but
> with an older microversion and it will be silently ignored. That is
> backward compatible but confusing from an end user perspective since it
> would appear to them that the filter is not being applied, when it fact
> it would be if they used the correct microversion.
>
> So do we want to start enforcing query parameters when listing servers
> to our defined list with microversion 2.66 or just continue to silently
> ignore them if used incorrectly?
>
> Note that starting in Rocky, the Neutron API will start rejecting
> unknown query parameteres [3] if the filter-validation extension is
> enabled (since Neutron doesn't use microversions). So there is some
> precedent in OpenStack for starting to enforce query parameters.
>
> [1] https://review.openstack.org/#/c/599276/
> [2]
> https://review.openstack.org/#/c/599276/23/nova/api/openstack/compute/schemas/servers.py
>
> [3]
> https://docs.openstack.org/releasenotes/neutron/rocky.html#upgrade-notes
My vote would be just change additionalProperties to False in the 599276
patch and be done with it.
Add a release note about the change, of course.
-jay
More information about the OpenStack-dev
mailing list