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

2017-08-07 Thread Lance Bragstad
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 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 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.
>
> I think that's fair. Given that you're not doing microversions and
> you aren't inclined to commit to CD, it's a pragmatic solution to
> mis-functionality that was introduced between code releases.
>
> It also sounds like an edge case where it's very unlikely that
> there's extant client code that is relying on that 403 to make
> decisions on next steps.
>
> The interop guideline is intentionally very strict and detailed, to
> make it clear how much you need to think about to really do it well,
> but in many cases should be considered as a tool for evaluating the
> extent of the damage a change might cause, not the law.
>
> Especially if you haven't got microversions available.
>
>
>
> __
> 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


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

2017-08-07 Thread Sean McGinnis
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 with this when we get some solid feedback on the impact.
> We started with CD as one of the fundamental
> constraints^H^H^H^H^Hgoals and to drop it should be a deliberate
> decision.

Did we ever state that goal somewhere?


__
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


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

2017-08-07 Thread Dean Troyer
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 CD as one of the fundamental
constraints^H^H^H^H^Hgoals and to drop it should be a deliberate
decision.

In addition to direct deployments, I found things like this [0] in a
quick search for who is publicly saying they (still) do CD, it is a
category I had not considered before and makes me think that this kind
of decision has a wider impact range than we may be aware of.

Looking in https://www.openstack.org/analytics for the 2017 User
Survey shows no production deployments on "trunk" but of course that
doesn't mean there are none.  I wonder if deployments using CD are (or
have now) fallen behind similarly to what we know to be the case with
deployments on releases, only maybe not quite as far?

dt

[0] 
https://devops.com/automic-empowers-cloud-continuous-delivery-openstack-integration/

-- 

Dean Troyer
dtro...@gmail.com

__
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


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

2017-08-07 Thread Chris Dent

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 developer army) that are trying to do this 
would be the *most* active in IRC and in the mailing list yet I don't really 
see any such activity (which either means we never break them, which seems 
highly unlikely, or that they don't communicate through the normal channels, 
ie they go through some vendor, or that they just flat out don't exist 
anymore).


I'd personally really like to know how they do it (especially if they do not 
have an associated developer army)... Because they have always been a pink 
elephant that I've heard exists 'somewhere' and they manage to make this all 
work 'somehow'.


I'd like to know this too. As Sean M says, we frequently make
compromises to support CD. In a sort of platonic sense, it is a
great goal, but it would be a lot easier to achieve if it had
participation from the people doing it.

Many deployments are several months behind. If _all_ (or even many)
deployments are that far behind, maybe we could consider saving ourselves
some pain?

--
Chris Dent  (⊙_⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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


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

2017-08-07 Thread Chris Dent

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


I think that's fair. Given that you're not doing microversions and
you aren't inclined to commit to CD, it's a pragmatic solution to
mis-functionality that was introduced between code releases.

It also sounds like an edge case where it's very unlikely that
there's extant client code that is relying on that 403 to make
decisions on next steps.

The interop guideline is intentionally very strict and detailed, to
make it clear how much you need to think about to really do it well,
but in many cases should be considered as a tool for evaluating the
extent of the damage a change might cause, not the law.

Especially if you haven't got microversions available.

--
Chris Dent  (⊙_⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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


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

2017-08-05 Thread Doug Hellmann
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 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 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 that we should not assume that
> if code merges ever it is a contract because someone might be
> following master. The contract should be for releases. We should do
> everything we can to avoid breaking people, but in the case of an API
> contract (behavior) that was never part of a final release, it should
> be understood this may change if needed until it is released.
> 
> This is just my $0.002 as this leads rapidly to "why bother having
> real releases" if everything is a contract, let someone take a
> snapshot where they're happy with the code to run. You're devaluing
> the actual releases.

I'm out here on this limb with you.

Doug

> 
> >> 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
> >
> > I would be inclined to accept this specific change as a bug fix not
> > requiring a version bump, because it is a corner case that I believe a
> > deployer would view as a bug, if they encountered it, and because it
> > was introduced prior to a named final release.
> > --
> > Kevin L. Mitchell 
> > __
> > 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


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

2017-08-04 Thread Sean McGinnis
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
> that track master, not fixed releases, so we need to take that
> level of
> compatibility into account.
> 
> 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 developer army) that are trying to do this
> would be the *most* active in IRC and in the mailing list yet I don't really
> see any such activity (which either means we never break them, which seems
> highly unlikely, or that they don't communicate through the normal channels,
> ie they go through some vendor, or that they just flat out don't exist
> anymore).
> 
> I'd personally really like to know how they do it (especially if they do not
> have an associated developer army)... Because they have always been a pink
> elephant that I've heard exists 'somewhere' and they manage to make this all
> work 'somehow'.
> 
> -Josh

I am curious too. I've been bothered by some of the compromised we've had to
make based on some people claiming CD from master is a "core tenet from the
beginning of OpenStack". But I have yet to find anywhere that we've stated
that we will commit to making continuous deployment from master a) possible,
and b) supported.

I would like us to either clearly declare that that type of deployment is
possible and expected and that the community agrees to support it, or that
it is possible for folks to try, but it will be on them if things don't work
out the way the had hoped.

Like I mentioned, we've made compromises based on this assertion, and I really
don't like that we've sacrificed good design and quality in order to support
a scenario that, as far as I've seen, 90+% of users and deployers would run
screaming from.

Sean

__
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


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

2017-08-04 Thread Joshua Harlow

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
compatibility into account.


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 developer army) that are trying to 
do this would be the *most* active in IRC and in the mailing list yet I 
don't really see any such activity (which either means we never break 
them, which seems highly unlikely, or that they don't communicate 
through the normal channels, ie they go through some vendor, or that 
they just flat out don't exist anymore).


I'd personally really like to know how they do it (especially if they do 
not have an associated developer army)... Because they have always been 
a pink elephant that I've heard exists 'somewhere' and they manage to 
make this all work 'somehow'.


-Josh

__
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


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

2017-08-04 Thread Morgan Fainberg
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
>> > compatibility into account.
>> >
>>
>> I am going to go out on a limb and say that we should not assume that
>> if code merges ever it is a contract because someone might be
>> following master. The contract should be for releases. We should do
>> everything we can to avoid breaking people, but in the case of an API
>> contract (behavior) that was never part of a final release, it should
>> be understood this may change if needed until it is released.
>>
>> This is just my $0.002 as this leads rapidly to "why bother having
>> real releases" if everything is a contract, let someone take a
>> snapshot where they're happy with the code to run. You're devaluing
>> the actual releases.
>
> In my view, following master imposes risks that deployers should
> understand and be prepared to mitigate; but I believe that it is our
> responsibility to acknowledge that they're doing it, and make a
> reasonable effort to not break them.  There are, of course, times when
> no reasonable effort will avoid breaking them, and in those cases, I
> feel that the reasonable course of action is to try to notify them of
> the upcoming breakage.  That's why then I went on to suggest that
> fixing this problem in keystone shouldn't require a version bump in
> this case: it _is_ a breakage that's being fixed.

I appreciate that this specific case you view as being in that
category, I was commenting more on the general case. I would go so far
as to outline exactly what we wont break for markers in-between
releases rather than what you've implied. I can come up with exactly
one case that should never be broken between releases (fixes that
change no behavior but address edge cases are fine): DB Schemas.

I am going to continue to say we cannot and should not commit to
treating anything that lands as a contract, it devalues the release
and ability of the developers to make shifts while working on a
release.

You and I may not agree here, but tracking master has risks and we
should allow for projects to make API changes for un-released APIs as
they see fit without version bumps.

Thanks for the feedback for this fix in specific, I think we came to
much the same conclusion in IRC but wanted some outside eyes on it.

Cheers,
--Morgan

__
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


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

2017-08-04 Thread Kevin L. Mitchell
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 that we should not assume that
> if code merges ever it is a contract because someone might be
> following master. The contract should be for releases. We should do
> everything we can to avoid breaking people, but in the case of an API
> contract (behavior) that was never part of a final release, it should
> be understood this may change if needed until it is released.
> 
> This is just my $0.002 as this leads rapidly to "why bother having
> real releases" if everything is a contract, let someone take a
> snapshot where they're happy with the code to run. You're devaluing
> the actual releases.

In my view, following master imposes risks that deployers should
understand and be prepared to mitigate; but I believe that it is our
responsibility to acknowledge that they're doing it, and make a
reasonable effort to not break them.  There are, of course, times when
no reasonable effort will avoid breaking them, and in those cases, I
feel that the reasonable course of action is to try to notify them of
the upcoming breakage.  That's why then I went on to suggest that
fixing this problem in keystone shouldn't require a version bump in
this case: it _is_ a breakage that's being fixed.
-- 
Kevin L. Mitchell 

signature.asc
Description: This is a digitally signed message part
__
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


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

2017-08-04 Thread Morgan Fainberg
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, and was not
>> part of the Ocata release.
>
> 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 that we should not assume that
if code merges ever it is a contract because someone might be
following master. The contract should be for releases. We should do
everything we can to avoid breaking people, but in the case of an API
contract (behavior) that was never part of a final release, it should
be understood this may change if needed until it is released.

This is just my $0.002 as this leads rapidly to "why bother having
real releases" if everything is a contract, let someone take a
snapshot where they're happy with the code to run. You're devaluing
the actual releases.

>> 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
>
> I would be inclined to accept this specific change as a bug fix not
> requiring a version bump, because it is a corner case that I believe a
> deployer would view as a bug, if they encountered it, and because it
> was introduced prior to a named final release.
> --
> Kevin L. Mitchell 
> __
> 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


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

2017-08-04 Thread Kevin L. Mitchell
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 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.

> 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

I would be inclined to accept this specific change as a bug fix not
requiring a version bump, because it is a corner case that I believe a
deployer would view as a bug, if they encountered it, and because it
was introduced prior to a named final release.
-- 
Kevin L. Mitchell 

signature.asc
Description: This is a digitally signed message part
__
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


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

2017-08-04 Thread Lance Bragstad


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


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

2017-08-04 Thread Kristi Nikolla
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  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-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


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

2017-08-04 Thread Matthew Treinish
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


signature.asc
Description: PGP 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


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

2017-08-04 Thread William M Edmonds

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)."
__
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-dev] [keystone][api] Backwards incompatible changes based on config

2017-08-04 Thread Lance Bragstad
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 backend) in SQL
- users can have a default project ID and a previous bug [1] fix made it
so users who were associated to a project via their
`default_project_id`, which is an attribute of the user, would be
corrected when that project was deleted
- when a project is deleted (DELETE /v3/projects/{project_id}) a
callback [2] [3] is invoked to unset that project ID from all users who
might have it set as their default project

This works great when both the identity and resource backends are
configured to use SQL. When the identity backend is configured to use
LDAP, the wheels fall off:

- a user attempts to remove a project (DELETE /v3/projects/{project_id})
- the identity callback is invoked and control is passed to the LDAP
identity driver implementation
- the LDAP implementation raises a 403 [4] because read/write LDAP is
not supported in keystone, and unsetting a project ID would classify as
a write operation

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.

Looking to get some advice from the API WG to see if this is something
we'll be able to address before rc or not. Thanks for reading!

Lance


[0] https://bugs.launchpad.net/keystone/+bug/1705081
[1]
https://github.com/openstack/keystone/commit/51d5597df729158d15b71e2ba80ab103df5d55f8
[2]
https://github.com/openstack/keystone/blob/4e986235713758f2df5ae12e66ca3e5e93edd551/keystone/identity/core.py#L489-L494
[3]
https://github.com/openstack/keystone/blob/4e986235713758f2df5ae12e66ca3e5e93edd551/keystone/identity/core.py#L523-L533
[4]
https://github.com/openstack/keystone/blob/4e986235713758f2df5ae12e66ca3e5e93edd551/keystone/identity/backends/ldap/core.py#L89-L92
[5]
http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html#evaluating-api-changes



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