API versioning
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
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
API version handling occurs inside the service-specific modules, eg openstackclient
* 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
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.
