<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 12, 2016 at 3:19 PM Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/12/2016 01:47 PM, Morgan Fainberg wrote:<br>
> This  also comes back to the conversation at the summit. We need to<br>
> propose the timeline to turn over for V3 (regardless of<br>
> voting/non-voting today) so that it is possible to set the timeline that<br>
> is expected for everything to get fixed (and where we are<br>
> expecting/planning to stop reverting while focusing on fixing the<br>
> v3-only changes).<br>
><br>
> I am going to ask the Keystone team to set forth the timeline and commit<br>
> to getting the pieces in order so that we can make v3-only voting rather<br>
> than playing the propose/revert game we're currently doing. A proposed<br>
> timeline and gameplan will only help at this point.<br>
<br>
A timeline would be good (proposed below), but there are also other bits<br>
of the approach we should consider.<br>
<br>
I would expect, for instance,<br>
gate-tempest-dsvm-neutron-identity-v3-only-full to be on keystone, and<br>
it does not appear to be. Is there a reason why?<br></blockquote><div> </div><div>We made this here: <a href="https://review.openstack.org/#/c/311169/">https://review.openstack.org/#/c/311169/</a></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
With that on keystone, devstack-gate, devstack, tempest the integrated<br>
space should be pretty well covered. There really is no need to also go<br>
stick this on glance, nova, cinder, neutron, swift I don't think,<br>
because they only really use keystone through pretty defined interfaces.<br>
<br>
Then some strategic use of nv jobs on things we know would have some<br>
additional interactions here (because we know they are currently broken<br>
or they do interesting things) like ironic, heat, trove, would probably<br>
be pretty useful.<br>
<br>
That starts building up the list of known breaks the keystone folks are<br>
tracking, which should get a drum beat every week in email about<br>
outstanding issues, and issues fixed.<br></blockquote><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">++ Sounds a good Idea, I'll work to make this happen.</span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The goal of gate-tempest-dsvm-neutron-identity-v3-only-full should not<br>
be for that to be voting, ever. It should be to use that as a good<br>
indicator that changing the default in devstack (and thus in the<br>
majority of upstream jobs) to not ever enable v2.<br></blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Because of how v3 support exists in projects (largely hidden behind<br>
keystoneauth), it is really unlikely to rando regress once fixed. There<br>
just aren't that many knobs a project has that would make that happen.<br>
So I think we can make forward progress without a voting backstop until<br>
we get to a point where we can just throw the big red switch (with<br>
warning) on a Monday (probably early in the Otaca cycle) and say there<br>
you go. It's now the project job to handle it. And they'll all get fair<br>
warning for the month prior to the big red switch.<br>
<br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>