auth_token middleware should default to v2.0 if version is not specified

[Dan Prince]

In a recent python-keystoneclient commit (d782a998474d92d4299b4404b69442f0288efc3b) we added support for the v3 API in the auth_token middleware.

In this commit we also switch the default keystone API version being used to v3.0. For backwards compat with the Grizzly release this is probably the wrong way to go. v2.0 should be the default and v3.0 is still supported if an application specifies it.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/24186

[Adam Young (ayoung)]

Please provide the information for the failure that you are seeing.

[Dan Prince (dan-prince)]

Okay. Sorry about this guys.

Turns out the reason I'm seeing this is because my setups don't actually have v3 enabled at the moment. (it is not in the paste config).

I will fix that. I suppose for Grizzly it is safe to say that this should be enabled.

Folsom won't have the v3.0 code so I think this is safe there too.

---

I still feel like this auth_token is ahead of the game here. I mean we clearly still default to using v2.0 in python keystoneclient (as a CLI) so why have auth_token use v3.0 now then? Shouldn't they be moved up together?

I will dowgrade the severity here since I'm able to fix this my side however but I still do think this is worth considering.

[Adam Young (ayoung)]

If you don;t have V3 enabled, then auth_token should be falling back to V2.0? Is that not happening?

[Dan Prince (dan-prince)]

Adam Young: No. It doesn't. The version controller is sort of dumb in that regard (as I learned today).

[Adam Young (ayoung)]

So here is what is happening in devstack versus smokestack:

at
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L392

            versions_supported_by_server = self._get_supported_versions()

_get_supported_versions() does a GET of "/" which, if the url is

http://127.0.0.1:5000/v2.0/ will get the version page for 2.0 and only does the proper autonegotiation if the url is

http://127.0.0.1:5000/

Which is what smokestack does.

[Dan Prince (dan-prince)]

ayoung: please don't reassign this without asking first :)

[Dan Prince (dan-prince)]

ayoung: the issue you describe sound like a new ticket (please file one)

This issue stands. I don't believe we should release python-keystoneclient which prefers/defaults to one version of the API when using the CLI and a different version when using the auth_token.py.

Put another way: if the CLI is going to use/prefer v2 I really feel like auth_token.py should have the same preference.

[Dolph Mathews (dolph)]

Non-keystone clients are attempting to parse the raw catalog returned by keystone; the format of the catalog changes with v3, and we're suddenly breaking those clients by providing them a catalog in a different format. Until we can revise those clients to query keystoneclient for the information they need, I think the best approach is to preserve the preference for v2.0 in auth_token

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/24186
Committed: http://github.com/openstack/python-keystoneclient/commit/692d97b85ab56b32e39e54ae7b47ed10762c9d91
Submitter: Jenkins
Branch: master

commit 692d97b85ab56b32e39e54ae7b47ed10762c9d91
Author: Dan Prince <email address hidden>
Date: Tue Mar 12 11:24:35 2013 -0400

    Use v2.0 api by default in auth_token middleware

    Fixes an issue that crept in with d782a99 where auth_token
    started defaulting to the v3.0 API by default when no version
    was specified.

    Given that bin/keystone still defaults to using the v2.0 API
    it seems like auth_token.py should too.

    Fixes LP Bug #1154144

    Change-Id: Ia5620bccc182bbc73cb60dcccb1f701304450e5a