Open Stack

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