Open Stack

On 05/12/2016 01:47 PM, Morgan Fainberg wrote:
>
>
> On Thu, May 12, 2016 at 10:42 AM, Sean Dague <sean at dague.net 
> <mailto: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.

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."


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.


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.


>
> --Morgan
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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