Open Stack

The Keystone v2 removal also broke Trove's gate.  Trove's functional
and scenario tests had Keystone v2 hard codings and also relied on a >
4 year old 'compat' client package in the python-troveclient that did
not have V3 support.

Both cases required a lot of scrambling find all the v2 hard codings
and add in v3 support.

I'm completely behind the V2 removal and am glad we've finally crossed
that bridge. The one thing that I think could have been handled better
was a longer amount of time between making devstack use V3 by default
and the actual removal of the V2 auth APIs.  There were 8 days between
these two commits.  It may have been better to switch devstack to use
v3 a half cycle or full cycle before removing the v2 APIs to allow
teams that had impacts more time to react.

On Sun, Oct 22, 2017 at 1:01 PM, Clint Byrum <clint at fewbar.com> wrote:
> 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev