Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

It sounds like there isn't any major objection to moving forward with a fix and getting this into Pike. I would be inclined to say the discussion here has elevated that priority since missing Pike would expose the 204 -> 403 in an official release. On 08/07/2017 03:54 AM, Chris Dent wrote: > On

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Mon, Aug 07, 2017 at 07:33:04AM -0500, Dean Troyer wrote: > On Mon, Aug 7, 2017 at 4:00 AM, Chris Dent wrote: > > Many deployments are several months behind. If _all_ (or even many) > > deployments are that far behind, maybe we could consider saving ourselves > > some

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Mon, Aug 7, 2017 at 4:00 AM, Chris Dent wrote: > Many deployments are several months behind. If _all_ (or even many) > deployments are that far behind, maybe we could consider saving ourselves > some pain? I would agree with this when we get some solid feedback on the

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, 4 Aug 2017, Joshua Harlow wrote: Any idea of who are these deployers? I think I knew once who they might have been but I'm not really sure anymore. Are they still doing this (and can afford doing it)? Why don't we hear more about them? I'd expect that deployers (and there associated

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, 4 Aug 2017, Lance Bragstad wrote: On 08/04/2017 03:45 PM, Kristi Nikolla wrote: 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

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

Excerpts from Morgan Fainberg's message of 2017-08-04 14:52:18 -0700: > On Fri, Aug 4, 2017 at 2:43 PM, Kevin L. Mitchell wrote: > > On Fri, 2017-08-04 at 16:45 -0400, Kristi Nikolla wrote: > >> Is this the case even if we haven’t made any final release with the change > >> that

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, Aug 04, 2017 at 03:44:32PM -0700, Joshua Harlow wrote: > Morgan Fainberg wrote: > >On Fri, Aug 4, 2017 at 3:09 PM, Kevin L. Mitchell wrote: > >>On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote: > Maybe not, but please do recall that there are many deployers

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

Morgan Fainberg wrote: On Fri, Aug 4, 2017 at 3:09 PM, Kevin L. Mitchell wrote: On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote: Maybe not, but please do recall that there are many deployers out there that track master, not fixed releases, so we need to take that

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, Aug 4, 2017 at 3:09 PM, Kevin L. Mitchell wrote: > On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote: >> > Maybe not, but please do recall that there are many deployers out >> > there >> > that track master, not fixed releases, so we need to take that >> > level of

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote: > > Maybe not, but please do recall that there are many deployers out > > there > > that track master, not fixed releases, so we need to take that > > level of > > compatibility into account. > > > > I am going to go out on a limb and say

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, Aug 4, 2017 at 2:43 PM, Kevin L. Mitchell wrote: > On Fri, 2017-08-04 at 16:45 -0400, 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

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, 2017-08-04 at 16:45 -0400, 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. Maybe not, but please

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

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

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

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

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

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

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

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

[openstack-dev] [keystone][api] Backwards incompatible changes based on config

Keystone had a bug reported [0] recently (that we are targeting to pike-rc1) that exposes an inconsistency in the API based on configuration. The happy path is as follows: - a deployment is configured to store projects (controlled by the resource backend) and users (controlled by the identity