On Tue, Mar 25, 2014 at 11:41 PM, Clint Byrum <[email protected]> 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 <[email protected]> > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
