Open Stack

 ---- On Tue, 18 Sep 2018 09:33:30 +0900 Alex Xu <soulxu at gmail.com> wrote ---- 
 > That only means after 599276 we only have servers API and os-instance-action API stopped accepting the undefined query parameter.
 > 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.

I too vote for doing it for all other API together. Restricting the unknown query or request param are very useful for API consistency. Item#1 in this etherpad https://etherpad.openstack.org/p/nova-api-cleanup

If you would like, i can propose a quick spec for that and positive response to do all together then we skip to do that in 599276 otherwise do it for GET servers in 599276. 

-gmann

 > Jay Pipes <jaypipes at gmail.com> 于2018年9月18日周二 上午4:07写道：
 >  __________________________________________________________________________
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 > 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
 >  
 >  __________________________________________________________________________
 >  OpenStack Development Mailing List (not for usage questions)
 >  Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
 >  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >