Open Stack

On Thu, May 12, 2016 at 10:42 AM, Sean Dague <sean at dague.net> wrote:

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

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.

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160512/5d490a4b/attachment.html>