On Thu, May 12, 2016 at 3:19 PM Sean Dague <[email protected]> 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. > > 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? >
We made this here: https://review.openstack.org/#/c/311169/ > > 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. > ++ Sounds a good Idea, I'll work to make this happen. > > 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. > We intend use this job as a indicator to find bugs related to this, but the idea to make this gate-tempest-dsvm-neutron-identity-v3-only-full voting is make sure that anyone are sending anything v3 incompatible. 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
