On 19 August 2015 at 20:37, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > On 8/19/2015 2:16 PM, Matt Riedemann wrote: >> On 8/19/2015 1:33 PM, Matt Riedemann wrote: >>> On 8/19/2015 12:18 PM, Chen CH Ji wrote: >>>> >>>> In doing [1] [2], some suggestions raised that those kind of change need >>>> microversion bump which is fine >>>> however, another concern raised on whether we need combine a set of >>>> those kind of changes (which may only change some error code) into one >>>> bump ? >>>> >>>> apparently there are pros and cons for doing so, combine makes API >>>> version bump not that frequent for minor changes >>>> but makes it hard to review and backport ... so any suggestions on how >>>> to handle ? Thanks >>>> >>>> >>>> [1]https://review.openstack.org/#/c/198753/ >>>> [2]https://review.openstack.org/#/c/173985/ >>>> >>>> Best Regards! >>>> >>>> Kevin (Chen) Ji 纪 晨 >>>> >>>> Engineer, zVM Development, CSTL >>>> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com >>>> Phone: +86-10-82454158 >>>> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian >>>> District, Beijing 100193, PRC >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> >>>> >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> I don't see why https://review.openstack.org/#/c/198753/ would require a >>> microversion bump. We've always allowed handling 500s and turning them >>> into more appropriate error codes, like a 400 in this case. >>> >>> As noted: >>> >>> >>> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html >>> >>> >>> >>> "Changing an error response code to be more accurate." is generally >>> acceptable. >>> >> >> https://review.openstack.org/#/c/173985/ doesn't require a version bump >> for the same reasons, IMO. If people are hung up on 400 vs 403 in that >> change, just make it a 400, we do it both ways in the compute API. >> > > I guess the problems are in the doc: > > http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63 > > - the list of status codes allowed for a particular request > > Example: an API previously could return 200, 400, 403, 404 and the > change would make the API now also be allowed to return 409. > > - changing a status code on a particular response > > Example: changing the return code of an API from 501 to 400. > > So in the one change, just return 400. In the service_get change where you > want to return a 400 but it's only returning a 404 today, then I guess > according to the doc you'd need a microversion bump. But what do we do > about fixing that bug in the v2 API? Do we not fix it? Do we return 404 > but v2.1 would return 400 with a microversion bump? That's equally > inconsistent and gross IMO.
I think the idea is we bump the microversion so the caller knows about the new error code being possible. Although I am tempted to say we make the change for all microversions, to stop the nasty 500 error, which does reduce the value of the version bump... In the v2 API, we should probably just change the 500 to a better return value as well, without and advertising. I think we used to allow that. Does that work? John __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
