<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 10:42 AM, 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">We just had to revert another v3 "fix" because it wasn't verified to<br>
work correctly in the gate - <a href="https://review.openstack.org/#/c/315631/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/315631/</a><br>
<br>
While I realize project-config patches are harder to test, you can do so<br>
with a bogus devstack-gate change that has the same impact in some cases<br>
(like the case above).<br>
<br>
I think the important bit on moving forward is that every patch here<br>
which might be disruptive has some manual verification about it working<br>
posted in review by v3 team members before we approve them.<br>
<br>
I also think we need to largely stay non voting on the v3 only job until<br>
we're quite confident that the vast majority of things are flipped over<br>
(for instance there remains an issue in nova <=> ironic communication<br>
with v3 last time I looked). That allows us to fix things faster because<br>
we don't wedge some slice of the projects in a gate failure.<br>
<br>
        -Sean<br>
<div><div class="h5"><br>
On 05/12/2016 11:08 AM, Raildo Mascena wrote:<br>
> Hi folks,<br>
><br>
> Although the Identity v2 API is deprecated as of Mitaka [1], some<br>
> services haven't implemented proper support to v3 yet. For instance,<br>
> we implemented a patch that made DevStack v3 by default that, when<br>
> merged, broke a lot of project gates in a few hours [2]. This<br>
> happened due to specific services incompatibility issues with Keystone<br>
> v3 API, such as hardcoded v2 usage, usage of removed keystoneclient CLI,<br>
> requesting v2 service tokens and the lack of keystoneauth session usage.<br>
><br>
> To discuss those points, we did a cross-project work<br>
> session in the Newton Summit[3]. One point we are working on at this<br>
> momment is creating gates to ensure the main OpenStack services<br>
> can live without the Keystone v2 API. Those gates setup devstack with<br>
> only Identity v3 enabled and run the Tempest suite on this environment.<br>
><br>
> We already did that for a few services, like Nova, Cinder, Glance,<br>
> Neutron, Swift. We are doing the same job for other services such<br>
> as Ironic, Magnum, Ceilometer, Heat and Barbican [4].<br>
><br>
> In addition, we are creating jobs to run functional tests for the<br>
> services on this identity v3-only environment[5]. Also, we have a couple<br>
> of other fronts that we are doing like removing some hardcoded v2 usage<br>
> [6], implementing keystoneauth sessions support in clients and APIs [7].<br>
><br>
> Our plan is to keep tackling as many items from the cross-project<br>
> session etherpad as we can, so we can achieve more confidence in moving<br>
> to a DevStack working v3-only, making sure everyone is prepared to work<br>
> with Keystone v3 API.<br>
><br>
> Feedbacks and reviews are very appreciated.<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/251530/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/251530/</a><br>
> [2] <a href="https://etherpad.openstack.org/p/v3-only-devstack" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/v3-only-devstack</a><br>
> [3] <a href="https://etherpad.openstack.org/p/newton-keystone-v3-devstack" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/newton-keystone-v3-devstack</a><br>
> [4] <a href="https://review.openstack.org/#/q/project:openstack-infra/project-config+branch:master+topic:v3-only-integrated" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/project:openstack-infra/project-config+branch:master+topic:v3-only-integrated</a><br>
> [5] <a href="https://review.openstack.org/#/q/topic:v3-only-functionals-tests-gates" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:v3-only-functionals-tests-gates</a><br>
> [6] <a href="https://review.openstack.org/#/q/topic:remove-hardcoded-keystone-v2" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:remove-hardcoded-keystone-v2</a><br>
> [7] <a href="https://review.openstack.org/#/q/topic:use-ksa" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:use-ksa</a><br>
><br>
> Cheers,<br>
><br>
> Raildo<br>
><br>
><br>
><br>
</div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>--Morgan</div></div></div></div>