API versioning

Registered by Doug Hellmann on 2012-05-01

We need to figure out how we are going to handle API versioning to make it uniform for all plugins. Should we, for example, delay creating the CommandManager until we know which version of the APIs we are going to be using? Or is it enough to centralize the API client management?

Blueprint information

Status:
Started
Approver:
None
Priority:
Medium
Drafter:
None
Direction:
Needs approval
Assignee:
Dean Troyer
Definition:
New
Series goal:
None
Implementation:
Good progress
Milestone target:
None
Started by
Dean Troyer on 2012-05-10

Related branches

Sprints

Whiteboard

API version handling occurs inside the service-specific modules, eg openstackclient.compute.client:
* API_VERSIONS - A mapping of versions to the client class that implements that version
* make_client(). This returns a client object of the requested version.

If the requested version is not supported, an exception is raised listing the supported versions.

===================
[discussion]

API version handling occurs inside the service-specific modules, eg openstackclient.compute.client.make_client(). This returns a client object of the requested version.

If the requested version is not supported, what do we do?
a) fail the request and the entire command
b) return the default version of the server?

(dhellmann) I think it should fail with a message about the supported version(s). "In the face of ambiguity, refuse the temptation to guess."

(dhellmann) If each module is going to implement its own version management (which I like) would there be any benefit to providing some common logic for doing the lookup and raising the exception? It could be as simple as a subclass of dict that raises the special "no-such-version" exception instead of KeyError.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.