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.
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?
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.
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.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
