Open Stack

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 at 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 at yuggoth.org]
> Sent: Friday, October 20, 2017 10:53 AM
> To: openstack-dev at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev