[openstack-dev] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

Jamie Lennox jamielennox at gmail.com
Mon May 16 00:00:50 UTC 2016

On 13 May 2016 at 04:15, Sean Dague <sean at dague.net> wrote:

> On 05/12/2016 01:47 PM, Morgan Fainberg wrote:
> > This  also comes back to the conversation at the summit. We need to
> > propose the timeline to turn over for V3 (regardless of
> > voting/non-voting today) so that it is possible to set the timeline that
> > is expected for everything to get fixed (and where we are
> > expecting/planning to stop reverting while focusing on fixing the
> > v3-only changes).
> >
> > I am going to ask the Keystone team to set forth the timeline and commit
> > to getting the pieces in order so that we can make v3-only voting rather
> > than playing the propose/revert game we're currently doing. A proposed
> > timeline and gameplan will only help at this point.
> A timeline would be good (proposed below), but there are also other bits
> of the approach we should consider.

That was my job to get sent to the TC. I'll get on it.

> I would expect, for instance,
> gate-tempest-dsvm-neutron-identity-v3-only-full to be on keystone, and
> it does not appear to be. Is there a reason why?

To test that keystone works with keystone v3? Otherwise what you're doing
is making it so that keystone's gate breaks every time neutron does
something that's not v3 compatible which brings it to our attention but
otherwise just gets in the way. The hope was to push the check job failure
back to the service so that its not purely keystone's job to run around and
fix all the other services when the incompatible change is discovered.

> With that on keystone, devstack-gate, devstack, tempest the integrated
> space should be pretty well covered. There really is no need to also go
> stick this on glance, nova, cinder, neutron, swift I don't think,
> because they only really use keystone through pretty defined interfaces.

Initially i would have agreed, and there has been a voting job on devstack
with keystone v3 only that proves that all of these services can work
together for at least a cycle. Where we got stung was all the plugins and
configuration options used in these services that don't get tested by that
integrated gate job. The hope was that by pushing these jobs out to the
services we would get more coverage of the service specific configurations
- but I can see that might not be working.

> Then some strategic use of nv jobs on things we know would have some
> additional interactions here (because we know they are currently broken
> or they do interesting things) like ironic, heat, trove, would probably
> be pretty useful.
> That starts building up the list of known breaks the keystone folks are
> tracking, which should get a drum beat every week in email about
> outstanding issues, and issues fixed.
> The goal of gate-tempest-dsvm-neutron-identity-v3-only-full should not
> be for that to be voting, ever. It should be to use that as a good
> indicator that changing the default in devstack (and thus in the
> majority of upstream jobs) to not ever enable v2.
> Because of how v3 support exists in projects (largely hidden behind
> keystoneauth), it is really unlikely to rando regress once fixed. There
> just aren't that many knobs a project has that would make that happen.
> So I think we can make forward progress without a voting backstop until
> we get to a point where we can just throw the big red switch (with
> warning) on a Monday (probably early in the Otaca cycle) and say there
> you go. It's now the project job to handle it. And they'll all get fair
> warning for the month prior to the big red switch.

I agree. Very early in the Otaca cycle is also the timeframe we had
discussed at summit so it looks like there is a good consensus there and
i'll get that proposal to TC this week.

For now we maintain the v3-only jobs as non-voting and we continue to push
the changes particularly to projects that are not tested in the default
devstack integrated gate test.

PS. I assume i'm right in assuming it's just impossible/infeasable to have
project-config changes determine all the jobs that are affected by a change
and run those as the project-config gate. It seems like one of the last few
places where we can commit something that breaks everyone and have never

> --
> Sean Dague
> http://dague.net
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160516/a58b6569/attachment.html>

More information about the OpenStack-dev mailing list