Open Stack

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

0. https://github.com/openstack/keystone/commit/51d5597df729158d15b71e2ba80ab103df5d55f8

> On Aug 4, 2017, at 3:52 PM, Matthew Treinish <mtreinish at kortar.org> wrote:
> 
> On Fri, Aug 04, 2017 at 03:35:38PM -0400, William M Edmonds wrote:
>> 
>> Lance Bragstad <lbragstad at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev