Bug 1043700

Summary: [RFE][python-keystoneclient]: Endpoint Versioning
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/python-keystoneclient/+spec/endpoint-versioning
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:44:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-17 00:41:24 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/python-keystoneclient/+spec/endpoint-versioning.

Description:

The following is written based on the python-openstack common cli (OSC)  but I think it is true for any of the clients attempting to talk to Keystone.

For OSC, to specify the version, the user passes in

 --os-identity-api-version=3
or
 --os-identity-api-version=2.0

No other values are currently supported.


0  Always strip any final / from the auth_url before proceeding
1. If  the auth_url ends in v3, assume the v3 api
2. If the auth_url ends in v2.0 assume the v2 api
3. If the auth_url does not end in either of the above, assume the v3 api.
4. If the user specifies an API version to use, that should override the above.
5. If the request API version does not match the URL, attempt to compose a valid URL
5.1 If the user wants the v2.0 api and the URL ends in /v3, remove the /v3 and  append /v2.0
5.2 If the user wants the v3 api and the URL ends in /v2.0, remove the /v2.0 and append /v3 and the URL does not end in /v3, append /v3
5.3 If the user wants the v2.0 api and the URL ends in /v2.0, use the URL as is
5.4 If the user wants the v3 api and the URL ends in /v3, use the URL as is
5.5 Otherwise, attempt to do auth_url discovery:


Discovery is basically: Assume the auth URL is the root of the tree.  Do an unauthenticated fetch on the URL.  Search through the resulting JSON for the "versions" key, which should contain an array.  Iterate through the members of the this collection until one has an "id" attribute that matches the requested API version, and select the corresponding "self" link as the auth_url from that point forward.

We don't want to do discover on every request, as it is expensive (complete round trip).  Once it has been performed, the updated AUTH_URL should be cached.  This is a tricky proposition, as the only updatable store is the python-keystore.  We don't want to prevent someone from updating their AUTH_URL if the server gets upgraded.

Specification URL (additional information):

None