[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.


More information about the OpenStack-dev mailing list