On 08/04/2017 03:45 PM, Kristi Nikolla wrote: > Is this the case even if we haven’t made any final release with the change > that introduced this issue? [0] > > It was only included in the Pike milestones and betas so far, and was not > part of the Ocata release. > > Therefore the call which now returns a 403 in master, returned a 2xx in > Ocata. So we would be fixing something which is broken on master rather > than changing a ‘contract’.
Good call - with that in mind I would be inclined to say we should fix the issue in Pike that way we keep the 204 -> 204 behavior the same across releases. But I'll defer to someone from the API WG just to make sure. > > 0. > https://github.com/openstack/keystone/commit/51d5597df729158d15b71e2ba80ab103df5d55f8 > >> On Aug 4, 2017, at 3:52 PM, Matthew Treinish <mtrein...@kortar.org> wrote: >> >> On Fri, Aug 04, 2017 at 03:35:38PM -0400, William M Edmonds wrote: >>> Lance Bragstad <lbrags...@gmail.com> wrote on 08/04/2017 02:37:40 PM: >>>> Properly fixing this would result in a 403 -> 204 status code, which >>>> requires an API version bump according to the interoperability >>>> guidelines [5] (note that keystone has not implemented microversions at >>>> this point). At the same time - not fixing the issues results in a 403 >>>> anytime a project is deleted while in this configuration. >>>> >>> The guidelines you linked actually say that this is allowed without a >>> version bump: >>> >>> "There are two types of change which do not require a version change:... or >>> responding with success (when the request was properly formed, but the >>> server had broken handling)." >> That's only for 500-599 response codes. The 'broken handling' there literally >> means broken as in the server couldn't handle the request. That bullet point >> is >> saying if you had a 500-599 response fixing the code so it's either a 4XX or >> a >> 2XX does not need a version. This specific case needs a version boundary >> because >> you going from a 403 -> 204. >> >> -Matt Treinish >> __________________________________________________________________________ >> 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 > > __________________________________________________________________________ > 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
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
