yeah... the revert broke us across all telemetry projects since we fixed plugins to adapt to v3. i'm very much for adapting to v3 since it's lingered around for years. i think given the time lapsed, if it breaks them, tough. the only issue i had with original patch was it merged on a Friday with no mention.
On 01/02/2016 9:48 PM, Steve Martinelli wrote: Thanks for bringing this up Sean. I went ahead and documented all the way the projects/gates/clients broke in an etherpad: <https://etherpad.openstack.org/p/v3-only-devstack> https://etherpad.openstack.org/p/v3-only-devstack These are all the projects that I know that were affected, if someone knows others, please add your findings. Sean, you can count me in on the volunteering effort to get this straightened out. Steve Sean Dague <s...@dague.net><mailto:s...@dague.net> wrote on 2016/02/01 12:21:50 PM: > From: Sean Dague <s...@dague.net><mailto:s...@dague.net> > To: openstack-dev > <openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org> > Date: 2016/02/01 12:23 PM > Subject: [openstack-dev] [all] towards a keystone v3 only devstack > > On Friday last week I hit the go button on a keystone v3 default patch > change in devstack. While that made it through tests for all the tightly > integrated projects, we really should have stacked up some other spot > tests to see how this was going to impact the rest of the ecosystem. > Novaclient, shade, osc, and a bunch of other things started faceplanting. > > The revert is here - https://review.openstack.org/#/c/274703/ - and will > move it's way through the gate once the tests complete. > > Going forward I think we need a more concrete plan on this transition. > I'm going to be -2 on any v3 related keystone changes in devstack until > we do, as it feels like we need to revert one of these patches about > every month for the last 6. > > I don't really care what format the plan takes, ML thread, wiki page, > spec. But we need one, and an owner (probably on the keystone side) to > walk us through how this transition goes. This is going to include some > point in the future where: > > 1. devstack configures v3 and v2 always, and devstack issues a warning > if v2 is enabled > 2. devstack configures v3 only, v2 can be enabled and v2 enabled is a > warning > 3. devstack removes v2 support > > The transition to stage 2 and stage 3 requires using Depends-On to stack > up some wider collection of tests to demonstrate that this works on > novaclient, heat, shade, osc, and anything that comes forward as being > broken by this last round. It's fine if we give people hard deadlines > that they need to get their jobs sorted, but like the removal of > extras.d, we need to be explicit about it. > > So, first off, we need a volunteer to step up to pull together this > plan. Any volunteers here? > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- gord
__________________________________________________________________________ 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
