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


> On Aug 4, 2017, at 3:52 PM, Matthew Treinish <> wrote:
> On Fri, Aug 04, 2017 at 03:35:38PM -0400, William M Edmonds wrote:
>> Lance Bragstad <> 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 Development Mailing List (not for usage questions)

Reply via email to