<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 May 2016 at 04:15, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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>
</span>A timeline would be good (proposed below), but there are also other bits<br>
of the approach we should consider.<br></blockquote><div><br></div><div>That was my job to get sent to the TC. I'll get on it.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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><br></div><div>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.<br> <br></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></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<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>
<br>
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.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.<br><br></div><div>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.<br></div><div> <br></div><div>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 noticed. <br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
        -Sean<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>