<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 05/12/2016 01:47 PM, Morgan Fainberg
wrote:<br>
</div>
<blockquote
cite="mid:CAGnj6as-OUPWUiAxqYCxOHYdwrH+ZrSBT=JNQ-+fkgsE-3JhzA@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://review.openstack.org/#/c/251530/"
rel="noreferrer" target="_blank">https://review.openstack.org/#/c/251530/</a><br>
> [2] <a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
I would like to draw a line in the sand and say that it has to be
there for Ocata. We should be working through the issues the Newton
release, and have a firm "Ocata should expect to be run V3 only,
with V2.0 an optional feature that can be enabled for backwards
compatibility if required."<br>
<br>
<br>
To me, Ocata is the finish line: there have been a lot of features
that Keystone has needed for a long time, and they are finally
starting to come together. V3 support, and all that it enables is
on of the big ones, and we need to give people enough information to
plan, and enough time to adjust.<br>
<br>
<br>
V3 support is essential for the way that most people are deploying:
User database coming from an external source like LDAP, service
users stored locally. We need to treat this as baseline, and make
sure that the deployment tools understand this and can make it
happen in their toolchains.<br>
<br>
<br>
<blockquote
cite="mid:CAGnj6as-OUPWUiAxqYCxOHYdwrH+ZrSBT=JNQ-+fkgsE-3JhzA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>--Morgan</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>