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.fainb...@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....@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 [fu...@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-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
