Open Stack

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