Open Stack

On Tue, Mar 25, 2014 at 11:41 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Dolph Mathews's message of 2014-03-25 19:01:17 -0700:
> > On Tue, Mar 25, 2014 at 5:50 PM, Russell Bryant <rbryant at redhat.com>
> wrote:
> >
> > > We discussed the deprecation of the v2 keystone API in the
> cross-project
> > > meeting today [1].  This thread is to recap and bring that discussion
> to
> > > some consensus.
> > >
> > > The issue is that Keystone has marked the v2 API as deprecated in
> Icehouse:
> > >
> > >     https://blueprints.launchpad.net/keystone/+spec/deprecate-v2-api
> > >
> > > If you use the API, deployments will get this in their logs:
> > >
> > > WARNING keystone.openstack.common.versionutils [-] Deprecated: v2 API
> is
> > > deprecated as of Icehouse in favor of v3 API and may be removed in K.
> > >
> > > The deprecation status is reflected in the API for end users, as well.
> > > For example, from the CLI:
> > >
> > >   $ keystone discover
> > >   Keystone found at http://172.16.12.38:5000/v2.0
> > >     - supports version v2.0 (deprecated) here
> > > http://172.16.12.38:5000/v2.0/
> > >
> > > My proposal is that this deprecation be reverted.  Here's why:
> > >
> > > First, it seems there isn't a common use of "deprecated".  To me,
> > > marking something deprecated means that the deprecated feature:
> > >
> > >  - has been completely replaced by something else
> > >
> >
> > >  - end users / deployers should take action to migrate to the
> > >    new thing immediately.
> > >
> >
> > >  - The project has provided a documented migration path
> >
> > >  - the old thing will be removed at a specific date/release
> > >
> >
> > Agree on all points. Unfortunately, we have yet to succeed on the
> > documentation front:
> >
> >
> >
> https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition
> >
> > >
> > > The problem with the above is that most OpenStack projects do not
> > > support the v3 API yet.
> > >
> > > From talking to Dolph in the meeting, it sounds like the intention is:
> > >
> > >  - fully support v2, just don't add features
> > >
> > >  - signal to other projects that they should be migrating to v3
> > >
> >
> > Above all else, this was our primary goal: to raise awareness about our
> > path forward, and to identify the non-obvious stakeholders that we needed
> > to work with in order to drop support for v2. With today's discussion as
> > evidence, I think we've succeeded in that regard :)
> >
> > >
> > > Given that intention, I believe the proper thing to do is to actually
> > > leave the API marked as fully supported / stable.  Keystone should be
> > > working with other OpenStack projects to migrate them to v3.  Once that
> > > is complete, deprecation can be re-visited.
> > >
> >
> > Happy to!
> >
> > Revert deprecation of the v2 API:
> https://review.openstack.org/#/c/82963/
> >
> > Although I'd prefer to apply this patch directly to milestone-proposed,
> so
> > we can continue into Juno with the deprecation in master.
> >
>
> As somebody maintaining a few master-chasing CD clouds, I'd like to ask
> you to please stop the squawking about deprecation until it has a definite
> replacement and most if not all OpenStack core projects are using it.
>
> 1 out of every 2 API calls on these clouds produces one of these errors
> in Keystone. That is just pointless. :-P
>

This is a good point. The other thing we discussed was whether it is
appropriate to announce "deprecation" in this way. I'm not sure that
logging *inside* the service is useful, but we don't yet have a way to
announce to the client that the call invoked is deprecated. We talked about
having a cross-project session at the summit, and collaborating with the
SDK team, to brainstorm solutions to that problem.

Doug



>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140326/4e12fdd9/attachment.html>