Keystone v2.0 documentation shows unsupported "versionId", "versionList", "versionInfo" fields

[Shri Javadekar]

The documentation of Openstack Keystone v2.0 [1] shows that when a user is authenticated, the return values will have a "versionId", "versionInfo", "versionStatus", etc.

However, based on the discussion I had on the #openstack-dev irc channel, it turns out that Keystone does not support these.

There are other auth implementation which try to be compatible with Keystone. They implement their auth schemes based on this documentation. Incorrect documentation causes these to break.

[1] http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_authenticate_v2.0_tokens_.html#POST_authenticate_v2.0_tokens_-Response

[Wyllys Ingersoll (wyllys66)]

If someone has a client that is breaking because it sees one of these "version" fields in the Tenant info section, then that client is being far to strict. Following the Robustness (i.e. Postals) law: "Be liberal in what you accept, be conservative in what you send." - the clients should be ignoring information that they don't need/want/like and not fail just because it's there, especially if it is documented.

3rd party auth systems are not wrong for following the keystone spec as it is currently documented. If that doc is incorrect, then it should be cleaned up. On the other hand, perhaps keystone SHOULD support these values. Is the bug in keystone or the documentation?

[Shri Javadekar (shrinand)]

If clients do not need a field, they can ignore the fields. However, in this case, the "versionId" field was used.

I'm using the jclouds java library for interacting with Keystone and Swift. It has a config option call "api-version" and defaults to "1". Things work just fine for cases when Keystone does not return the "versionId". However, if Keystone does return a "versionId", jclouds expects that the "api-version" should be exactly identical to the "versionId" returned by Keystone. In this case, the "versionId" returned was "1.0". Since "1" != "1.0" (string comparison), things failed :(.

Maybe there is some configuration required for jclouds, maybe there are some other improvements that could be done too. But that doesn't take away the fact there is a bug on the Keystone side.

Right now, I see that the documentation and the Keystone implementation are not in sync. Based on the discussion on the irc channel, the bug is in the documentation.

[Wyllys Ingersoll (wyllys66)]

That sounds like this could also be a bug in jClouds, have you talked to them? The versionId in the tenant field refers to the API version that the tenant's endpoint is using. If jclouds has an external config option that supercedes this value and can cause a conflict, then jclouds would seem to be in the wrong by not handling the conflict correctly. Perhaps jClouds should defer to the values returned in the token and not assume a fixed configuration value.

[Shri Javadekar (shrinand)]

I'm taking up the issue with jclouds as well. Just wanted to point out the Keystone bug here so that it gets fixed appropriately.

[Shri Javadekar (shrinand)]

The situation is a little more unfortunate. Bigger cloud providers like HP also seem have implemented an auth scheme that returns the "versionId". See [1] below. It talks about a problem arisen because the "versionId" differed between "1.0" to "1".

If the "versionId" shouldn't have been present at all and the documentation reflected that, this wouldn't have happened I guess.

[1] https://issues.apache.org/jira/browse/JCLOUDS-311

[Dolph Mathews (dolph)]

OpenStack has never actually supported these attributes - I suggest that the examples in documentation be updated to remove them. AFAIK, they don't even appear in the v2 WADL/XSD specification anywhere (?).

[OpenStack Infra (hudson-openstack)]

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

[Atsushi SAKAI (sakaia)]

Is there any progress?

[Steve Martinelli (stevemar)]

i am very unclear as to what the bug is here (from a keystone and keystoneclient perspective). we do not support or advertise the user of versionId, versionList and versionInfo in our APIs. if you are using a third party library, file a bug with them.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/263080
Committed: https://git.openstack.org/cgit/openstack/api-site/commit/?id=1f5168013e0e97725ac9cbf9bbe7740d57ec0ebf
Submitter: Jenkins
Branch: master

commit 1f5168013e0e97725ac9cbf9bbe7740d57ec0ebf
Author: Diane Fleming <email address hidden>
Date: Sun Jan 3 19:18:00 2016 -0600

    Remove versionId, versionInfo, and versionStatus attributes

    Change-Id: Ifd18ad7f6aff8bf7383f47537590c544e11c605b
    Closes-Bug: #1273831