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 F
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 pain?
>
> I would agree w
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 impact.
We started with C
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 de
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 wo
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 introduced this is
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 out
> there
> >>
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
level of
compatibilit
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
>> > compatibilit
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
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 and betas so far, a
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
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
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 woul
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
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 f
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 back
17 matches
Mail list logo
