Open Stack

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