On 05/12/2016 06:39 PM, gordon chung wrote:
On 12/05/2016 1:47 PM, Morgan Fainberg wrote:
On Thu, May 12, 2016 at 10:42 AM, Sean Dague <[email protected]
<mailto:[email protected]>> 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.
can anyone confirm when we deprecated keystonev2? i see a bp[1] related
to deprecation that was 'implemented' in 2013.
i realise switching to v3 breaks many gates but it'd be good to at some
point say it's not 'keystonev3 breaking the gate' but rather 'projectx
is breaking the gate because they are using keystonev2 which was
deprecated 4 cycles ago'. given the deprecation period allowed already,
can we say "here's some help, fix/merge this by
<date_before_end_of_newton>, or your gate will be broken until then"?
(assuming all the above items by Raildo doesn't fix everything).
I'd like to say Ocata.
[1] https://blueprints.launchpad.net/keystone/+spec/deprecate-v2-api
cheers,
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
