Versioned RPC APIs
The existing rpc API is pretty lightweight and seems to work quite well. One
limitation is that there is nothing provided to help with different versions of
services talking to each other. It may work … or it may not. If it doesn’t,
the failure you get could be something obvious, or it could be something really
bad and bizarre where an operation fails half-way through, leaving things in a
bad state.
The end goal with this effort will be to make sure that as you upgrade from
Essex to Folsom, any messages originating from an Essex service can and will be
correctly processed by a Folsom service. If that fails, then the failure
should be immediate and obvious that a message was rejected due to a version
issue.
Blueprint information
- Status:
- Complete
- Approver:
- Vish Ishaya
- Priority:
- Essential
- Drafter:
- Russell Bryant
- Direction:
- Approved
- Assignee:
- Russell Bryant
- Definition:
- Approved
- Series goal:
- Accepted for folsom
- Implementation:
-
Implemented
- Milestone target:
-
2012.2
- Started by
- Russell Bryant
- Completed by
- Thierry Carrez
Related branches
Related bugs
Sprints
Whiteboard
https:/
Gerrit topic: https:/
Addressed by: https:/
Add base support for rpc API versioning.
Addressed by: https:/
Add version to the cert rpc API.
Addressed by: https:/
Add version to consoleauth rpc API.
Addressed by: https:/
Add version to console rpc API.
Addressed by: https:/
Add version to scheduler rpc API.
Addressed by: https:/
Add version to compute rpc API.
QA:
----
Internal - Services able to handle multiple versioned client requests
Test Impact - None
Work Items
Dependency tree
* Blueprints in grey have been implemented.
