settingsLogin | Registersettings

[openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

0 votes

Should this kind of change be discussed and have an agreement of the TC
and User committee?

---------- Forwarded message ----------
From: Lance Bragstad lbragstad@gmail.com
Date: Fri, Oct 20, 2017 at 12:08 AM
Subject: [Openstack-operators] [keystone][all] v2.0 API removal
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>, openstack-operators@lists.openstack.org

Hey all,

Now that we're finishing up the last few bits of v2.0 removal, I'd like to
send out a reminder that Queens will not include the v2.0 keystone APIs
except the ec2-api. Authentication and validation of v2.0 tokens has been
removed (in addition to the public and admin APIs) after a lengthy
deprecation period.

Let us know if you have any questions.

Thanks!


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--
Tang Yaguang


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

asked Oct 23, 2017 in openstack-dev by Yaguang_Tang (1,180 points)   1 2 4

11 Responses

0 votes

That is a very interesting question.

It comes from the angle of OpenStack the product more then from the standpoint of any one OpenStack project.

I know the TC's been shying away from these sorts of questions, but this one has a pretty big impact. TC?

Thanks,
Kevin


From: Yaguang Tang [heut2008@gmail.com]
Sent: Thursday, October 19, 2017 7:59 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

Should this kind of change be discussed and have an agreement of the TC and User committee?

---------- Forwarded message ----------
From: Lance Bragstad lbragstad@gmail.com
Date: Fri, Oct 20, 2017 at 12:08 AM
Subject: [Openstack-operators] [keystone][all] v2.0 API removal
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org, openstack-operators@lists.openstack.org

Hey all,

Now that we're finishing up the last few bits of v2.0 removal, I'd like to send out a reminder that Queens will not include the v2.0 keystone APIs except the ec2-api. Authentication and validation of v2.0 tokens has been removed (in addition to the public and admin APIs) after a lengthy deprecation period.

Let us know if you have any questions.

Thanks!


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--
Tang Yaguang


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 20, 2017 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

On 2017-10-20 10:59:36 +0800 (+0800), Yaguang Tang wrote:
Should this kind of change be discussed and have an agreement of
the TC and User committee?
[...]

Looks like this thread has split since bouncing back in from the
operators ML, but I replied in the "other" dev ML thread for this
topic already:

http://lists.openstack.org/pipermail/openstack-dev/2017-October/123813.html

Do you have any suggested guidelines for the scope or scale of
impact for some deprecations and removals which should be held to a
higher standard? Would you be willing to work with the TC to update
the existing deprecation tag (or come up with an additional one) to
covers this additional policy?
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Oct 20, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
[...]
I know the TC's been shying away from these sorts of questions,
but this one has a pretty big impact. TC?
[...]

The OpenStack Technical Committee isn't really a bludgeon with which
to beat teams when someone in the community finds fault with a
decision; it drafts/revises policy and arbitrates disputes between
teams. What sort of action are you seeking in regard to the Keystone
team finally acting this cycle on removal of their long-deprecated
legacy API, and with what choices of theirs do you disagree?

Do you feel the deprecation was not communicated widely enough? Do
you feel that SDKs haven't been updated with sufficient support for
the v3 API? Are you concerned that lack of v2 API support will
prevent organizations running the upcoming Queens release from
qualifying for interoperability trademarks? Something else entirely?
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Oct 20, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

No, I'm not saying its the TC teams job to bludgeon folks.

I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.

I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.

Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?

Thanks,
Kevin


From: Jeremy Stanley [fungi@yuggoth.org]
Sent: Friday, October 20, 2017 10:53 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
[...]
I know the TC's been shying away from these sorts of questions,
but this one has a pretty big impact. TC?
[...]

The OpenStack Technical Committee isn't really a bludgeon with which
to beat teams when someone in the community finds fault with a
decision; it drafts/revises policy and arbitrates disputes between
teams. What sort of action are you seeking in regard to the Keystone
team finally acting this cycle on removal of their long-deprecated
legacy API, and with what choices of theirs do you disagree?

Do you feel the deprecation was not communicated widely enough? Do
you feel that SDKs haven't been updated with sufficient support for
the v3 API? Are you concerned that lack of v2 API support will
prevent organizations running the upcoming Queens release from
qualifying for interoperability trademarks? Something else entirely?
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 20, 2017 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

Let me clarify a few things regarding the V2.0 removal:

  • This has been planned for years at this point. At one time (I am
    looking for the documentation, once I find it I'll include it on this
    thread) we worked with Nova and the TC to set forth a timeline on the
    removal. Part of that agreement was that this was a one-time deal. We
    would remove the V2.0 API in favor of the v3 API but would never
    remove another API going forward.

    A few reasons for removing the V2.0 API that were discussed and
    drove the decision:

    1) The V2.0 API had behavior that was explicitly breaking the security model:

    • A user could authenticate with a scope not the default
      domain) which could lead to oddities in enforcement when using v2.0
      APIs and introduced a number of edge cases. This could not be fixed
      without breaking the V2.0 API contract and every single change to V3
      and features required a lot of time to ensure V2.0 was not breaking
      and had appropriate translations to/from the different data formats.

    • The V2.0 AUTH API included the token (secure) data in the URL
      path, this means that all logs from apache (or other web servers and
      wsgi apps) had to be considered privileged and could not be exposed
      for debugging purposes (and in some environments may not be accessed
      without significant access-controls). This also could not be fixed
      without breaking the V2.0 API contract.

    • The V2.0 policy was effectively hard coded (effectively) to
      use "admin" and "member" roles. Retrofitting the APIs to support fully
      policy was extremely difficult and could break default behaviors
      (easily) in many environments. This was also deemed to be mostly
      unfix-able without breaking the V2.0 API contract.

      In short, the maintenance on V2.0 API was significant, it was a
      lot of work to maintain especially since the API could not receive any
      active development due to lacking basic features introduced in v3.0.
      There were also a significant number of edge cases where v3 had some
      very hack-y support for features (required in openstack services) via
      auth to support the possibility of v2->v3 translations.

    2) V2.0 had been bit rotting. Many items had limited testing and
    were found to be broken. Adding tests that were both V3 and V2.0 aware
    added another layer of difficulty in maintaining the API, much of the
    time we had to spin many new patches to ensure that we didn't break
    v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API
    call, we would be somewhat forced into breaking the API contract).

    3) The Keystone team is acutely aware that this was a painful
    transition and made the choice to drop the API even in that light. The
    choice of "breaking the API contract" a number of times verses
    lightening the developer load (we are strapped for resources working
    on Keystone as are many services, the overhead and added load makes it
    mostly untenable) and do a single (large) change with the
    understanding that V3 APIs cannot be removed was preferable.

The TC agreed to this removal. The service teams agreed to this
removal. This was telegraphed as much as we could via deprecation and
many, many, many discussions on this topic. There really was no good
solution, we took the solution that was the best for OpenStack in our
opinion based upon the place where Keystone is.

We can confidently commit to the following:
* v3 APIs (Even the ones we dislike) will not go away
* barring a massive security hole, we will not break the API
contracts on V3] (we may add data, we will not remove/restructure
data)
* If we implement microversions, you may see API changes (similar to
how nova works), but as of today, we do not implement microversions

We have worked with defcore/refstack, qa teams, all services (I think
we missed one, it has since been fixed), clients, SDK(s), etc to
ensure that as much support as possible is in place to make utilizing
V3 easy.

On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M Kevin.Fox@pnnl.gov wrote:
No, I'm not saying its the TC teams job to bludgeon folks.

I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.

I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.

Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?

Thanks,
Kevin


From: Jeremy Stanley [fungi@yuggoth.org]
Sent: Friday, October 20, 2017 10:53 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
[...]

I know the TC's been shying away from these sorts of questions,
but this one has a pretty big impact. TC?
[...]

The OpenStack Technical Committee isn't really a bludgeon with which
to beat teams when someone in the community finds fault with a
decision; it drafts/revises policy and arbitrates disputes between
teams. What sort of action are you seeking in regard to the Keystone
team finally acting this cycle on removal of their long-deprecated
legacy API, and with what choices of theirs do you disagree?

Do you feel the deprecation was not communicated widely enough? Do
you feel that SDKs haven't been updated with sufficient support for
the v3 API? Are you concerned that lack of v2 API support will
prevent organizations running the upcoming Queens release from
qualifying for interoperability trademarks? Something else entirely?
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 21, 2017 by Morgan_Fainberg (17,320 points)   2 4 9
0 votes

In addendum, the final v2.0 (EC2-API) path will eventually be removed
(mitaka +7, the "T" release). The v3 versions (where they exist) will
continue to be maintained and not removed.

On Fri, Oct 20, 2017 at 5:16 PM, Morgan Fainberg
morgan.fainberg@gmail.com wrote:
Let me clarify a few things regarding the V2.0 removal:

  • This has been planned for years at this point. At one time (I am
    looking for the documentation, once I find it I'll include it on this
    thread) we worked with Nova and the TC to set forth a timeline on the
    removal. Part of that agreement was that this was a one-time deal. We
    would remove the V2.0 API in favor of the v3 API but would never
    remove another API going forward.

    A few reasons for removing the V2.0 API that were discussed and
    drove the decision:

    1) The V2.0 API had behavior that was explicitly breaking the security model:

    • A user could authenticate with a scope not the default
      domain) which could lead to oddities in enforcement when using v2.0
      APIs and introduced a number of edge cases. This could not be fixed
      without breaking the V2.0 API contract and every single change to V3
      and features required a lot of time to ensure V2.0 was not breaking
      and had appropriate translations to/from the different data formats.

    • The V2.0 AUTH API included the token (secure) data in the URL
      path, this means that all logs from apache (or other web servers and
      wsgi apps) had to be considered privileged and could not be exposed
      for debugging purposes (and in some environments may not be accessed
      without significant access-controls). This also could not be fixed
      without breaking the V2.0 API contract.

    • The V2.0 policy was effectively hard coded (effectively) to
      use "admin" and "member" roles. Retrofitting the APIs to support fully
      policy was extremely difficult and could break default behaviors
      (easily) in many environments. This was also deemed to be mostly
      unfix-able without breaking the V2.0 API contract.

      In short, the maintenance on V2.0 API was significant, it was a
      lot of work to maintain especially since the API could not receive any
      active development due to lacking basic features introduced in v3.0.
      There were also a significant number of edge cases where v3 had some
      very hack-y support for features (required in openstack services) via
      auth to support the possibility of v2->v3 translations.

    2) V2.0 had been bit rotting. Many items had limited testing and
    were found to be broken. Adding tests that were both V3 and V2.0 aware
    added another layer of difficulty in maintaining the API, much of the
    time we had to spin many new patches to ensure that we didn't break
    v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API
    call, we would be somewhat forced into breaking the API contract).

    3) The Keystone team is acutely aware that this was a painful
    transition and made the choice to drop the API even in that light. The
    choice of "breaking the API contract" a number of times verses
    lightening the developer load (we are strapped for resources working
    on Keystone as are many services, the overhead and added load makes it
    mostly untenable) and do a single (large) change with the
    understanding that V3 APIs cannot be removed was preferable.

The TC agreed to this removal. The service teams agreed to this
removal. This was telegraphed as much as we could via deprecation and
many, many, many discussions on this topic. There really was no good
solution, we took the solution that was the best for OpenStack in our
opinion based upon the place where Keystone is.

We can confidently commit to the following:
* v3 APIs (Even the ones we dislike) will not go away
* barring a massive security hole, we will not break the API
contracts on V3] (we may add data, we will not remove/restructure
data)
* If we implement microversions, you may see API changes (similar to
how nova works), but as of today, we do not implement microversions

We have worked with defcore/refstack, qa teams, all services (I think
we missed one, it has since been fixed), clients, SDK(s), etc to
ensure that as much support as possible is in place to make utilizing
V3 easy.

On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M Kevin.Fox@pnnl.gov wrote:

No, I'm not saying its the TC teams job to bludgeon folks.

I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.

I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.

Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?

Thanks,
Kevin


From: Jeremy Stanley [fungi@yuggoth.org]
Sent: Friday, October 20, 2017 10:53 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
[...]

I know the TC's been shying away from these sorts of questions,
but this one has a pretty big impact. TC?
[...]

The OpenStack Technical Committee isn't really a bludgeon with which
to beat teams when someone in the community finds fault with a
decision; it drafts/revises policy and arbitrates disputes between
teams. What sort of action are you seeking in regard to the Keystone
team finally acting this cycle on removal of their long-deprecated
legacy API, and with what choices of theirs do you disagree?

Do you feel the deprecation was not communicated widely enough? Do
you feel that SDKs haven't been updated with sufficient support for
the v3 API? Are you concerned that lack of v2 API support will
prevent organizations running the upcoming Queens release from
qualifying for interoperability trademarks? Something else entirely?
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 21, 2017 by Morgan_Fainberg (17,320 points)   2 4 9
0 votes

Ok. Cool. Didn't know that. Sounds like all due diligence was done then (and maybe plus some :). Thanks for the background info.

Kevin


From: Morgan Fainberg [morgan.fainberg@gmail.com]
Sent: Friday, October 20, 2017 5:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

Let me clarify a few things regarding the V2.0 removal:

  • This has been planned for years at this point. At one time (I am
    looking for the documentation, once I find it I'll include it on this
    thread) we worked with Nova and the TC to set forth a timeline on the
    removal. Part of that agreement was that this was a one-time deal. We
    would remove the V2.0 API in favor of the v3 API but would never
    remove another API going forward.

    A few reasons for removing the V2.0 API that were discussed and
    drove the decision:

    1) The V2.0 API had behavior that was explicitly breaking the security model:

    • A user could authenticate with a scope not the default
      domain) which could lead to oddities in enforcement when using v2.0
      APIs and introduced a number of edge cases. This could not be fixed
      without breaking the V2.0 API contract and every single change to V3
      and features required a lot of time to ensure V2.0 was not breaking
      and had appropriate translations to/from the different data formats.

    • The V2.0 AUTH API included the token (secure) data in the URL
      path, this means that all logs from apache (or other web servers and
      wsgi apps) had to be considered privileged and could not be exposed
      for debugging purposes (and in some environments may not be accessed
      without significant access-controls). This also could not be fixed
      without breaking the V2.0 API contract.

    • The V2.0 policy was effectively hard coded (effectively) to
      use "admin" and "member" roles. Retrofitting the APIs to support fully
      policy was extremely difficult and could break default behaviors
      (easily) in many environments. This was also deemed to be mostly
      unfix-able without breaking the V2.0 API contract.

      In short, the maintenance on V2.0 API was significant, it was a
      lot of work to maintain especially since the API could not receive any
      active development due to lacking basic features introduced in v3.0.
      There were also a significant number of edge cases where v3 had some
      very hack-y support for features (required in openstack services) via
      auth to support the possibility of v2->v3 translations.

    2) V2.0 had been bit rotting. Many items had limited testing and
    were found to be broken. Adding tests that were both V3 and V2.0 aware
    added another layer of difficulty in maintaining the API, much of the
    time we had to spin many new patches to ensure that we didn't break
    v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API
    call, we would be somewhat forced into breaking the API contract).

    3) The Keystone team is acutely aware that this was a painful
    transition and made the choice to drop the API even in that light. The
    choice of "breaking the API contract" a number of times verses
    lightening the developer load (we are strapped for resources working
    on Keystone as are many services, the overhead and added load makes it
    mostly untenable) and do a single (large) change with the
    understanding that V3 APIs cannot be removed was preferable.

The TC agreed to this removal. The service teams agreed to this
removal. This was telegraphed as much as we could via deprecation and
many, many, many discussions on this topic. There really was no good
solution, we took the solution that was the best for OpenStack in our
opinion based upon the place where Keystone is.

We can confidently commit to the following:
* v3 APIs (Even the ones we dislike) will not go away
* barring a massive security hole, we will not break the API
contracts on V3] (we may add data, we will not remove/restructure
data)
* If we implement microversions, you may see API changes (similar to
how nova works), but as of today, we do not implement microversions

We have worked with defcore/refstack, qa teams, all services (I think
we missed one, it has since been fixed), clients, SDK(s), etc to
ensure that as much support as possible is in place to make utilizing
V3 easy.

On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M Kevin.Fox@pnnl.gov wrote:
No, I'm not saying its the TC teams job to bludgeon folks.

I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.

I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.

Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?

Thanks,
Kevin


From: Jeremy Stanley [fungi@yuggoth.org]
Sent: Friday, October 20, 2017 10:53 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
[...]

I know the TC's been shying away from these sorts of questions,
but this one has a pretty big impact. TC?
[...]

The OpenStack Technical Committee isn't really a bludgeon with which
to beat teams when someone in the community finds fault with a
decision; it drafts/revises policy and arbitrates disputes between
teams. What sort of action are you seeking in regard to the Keystone
team finally acting this cycle on removal of their long-deprecated
legacy API, and with what choices of theirs do you disagree?

Do you feel the deprecation was not communicated widely enough? Do
you feel that SDKs haven't been updated with sufficient support for
the v3 API? Are you concerned that lack of v2 API support will
prevent organizations running the upcoming Queens release from
qualifying for interoperability trademarks? Something else entirely?
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 21, 2017 by Fox,_Kevin_M (29,360 points)   1 3 4
0 votes

On Fri, Oct 20, 2017 at 7:16 PM, Morgan Fainberg morgan.fainberg@gmail.com
wrote:

Let me clarify a few things regarding the V2.0 removal:

  • This has been planned for years at this point. At one time (I am
    looking for the documentation, once I find it I'll include it on this
    thread) we worked with Nova and the TC to set forth a timeline on the
    removal. Part of that agreement was that this was a one-time deal. We
    would remove the V2.0 API in favor of the v3 API but would never
    remove another API going forward.

Glad to hear this. Does this apply to all projects? Deprecation and removal
of API versions or versions of features (especially before new version of
feature has parity and proven scale to older version of feature) has been a
pain point for large production public clouds in terms of keeping in sync
with upstream which then adversely affects the ability of that organization
to contribute back to upstream due to having to stay on older versions. It
can quickly become too painful, risky, and costly to ever reconcile
eventually leading to the organization no longer meaningful contributing to
projects where they've drifted too far all together. I consider this
scenario to be very unfortunate for the customer's of that public cloud as
well as the OpenStack project itself.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 21, 2017 by Cody_A.W._Somerville (400 points)   1
0 votes

On 2017-10-20 22:50:53 +0000 (+0000), Fox, Kevin M wrote:
[...]
Ideally, there should be an OpenStack overarching architecture
team of some sort to handle this kind of thing I think.

There was one for a while, but it dissolved due to lack of community
participation. If you'd like to help reboot it, Clint B. can
probably provide you with background on the previous attempt.

Without such an entity though, I think the TC is probably
currently the best place to discuss it though?

Contrary to the impression some people seem to have, the TC is not
primarily composed of cloud architects; it's an elected body of
community leaders who seek informed input from people like you. I've
personally found no fault in the process and timeline the Keystone
team followed in this situation but I'm also not the primary
audience for their software, so it's good to hear from those who are
about ways to improve similar cases in the future. However, I also
understand that no matter how widely and carefully changes are
communicated, there's only so much anyone can do to avoid surprising
the subset of users who simply don't pay attention.
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Oct 21, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

Excerpts from Jeremy Stanley's message of 2017-10-21 13:37:01 +0000:

On 2017-10-20 22:50:53 +0000 (+0000), Fox, Kevin M wrote:
[...]

Ideally, there should be an OpenStack overarching architecture
team of some sort to handle this kind of thing I think.

There was one for a while, but it dissolved due to lack of community
participation. If you'd like to help reboot it, Clint B. can
probably provide you with background on the previous attempt.

I'd be in support of reviving the Architecture Working Group (SIG?).

Would need to see more people commit to it though. It mostly felt like
a place for Thierry and me to write down our ideas, and a title to put
on a room at the PTG so we could have cross-project discussions about
our ideas.

That said, there is a cross-project process that works pretty well when
one project needs to ask for changes from other projects:

https://docs.openstack.org/project-team-guide/cross-project.html

I believe the Keystone team followed this process despite some fumbles
early in the v3 story.

Without such an entity though, I think the TC is probably
currently the best place to discuss it though?

Contrary to the impression some people seem to have, the TC is not
primarily composed of cloud architects; it's an elected body of
community leaders who seek informed input from people like you. I've
personally found no fault in the process and timeline the Keystone
team followed in this situation but I'm also not the primary
audience for their software, so it's good to hear from those who are
about ways to improve similar cases in the future. However, I also
understand that no matter how widely and carefully changes are
communicated, there's only so much anyone can do to avoid surprising
the subset of users who simply don't pay attention.

Right, the TC is more or less a legislative body. They can set policy
but they don't actually make sure the vision is implemented directly.

I made an argument that there's a need for an executive branch to get
hard things done here:

http://fewbar.com/2017/02/open-source-governance-needs-presidents/

Without some kind of immediate executive that sits above project levels,
we'll always be designing by committee and find our silos getting deeper.

All of that said, I believe the Keystone team did a great job of getting
something hard done. As Morgan states, it was a 100% necessary evolution
and required delicate orchestration. Well done Keystone team!


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 22, 2017 by Clint_Byrum (40,940 points)   4 5 9
...