Difference between revisions of "Trove-rpc-versioning"
Dan Nguyen (talk | contribs) m (→Goals) |
Dan Nguyen (talk | contribs) m (→Work) |
||
Line 32: | Line 32: | ||
self.client = rpc.get_client(target, version_cap=version_cap) | self.client = rpc.get_client(target, version_cap=version_cap) | ||
</pre> | </pre> | ||
+ | |||
+ | ==== RPC calls ==== | ||
+ | * We can check if the client can send a specific version | ||
+ | https://github.com/openstack/nova/blob/master/nova/conductor/rpcapi.py#L423 |
Revision as of 22:50, 10 April 2014
Contents
Intro
This page describes the intent to implement oslo messaging's API Version Negotiation in Trove
Oslo
Oslo/Messaging#API_Version_Negotiation
Goals
Prevent backward incompatibility between Trove components
The API can send an older version of a message/call to a newer message handler without issue The API can check to see if the message handler can receive a newer version of a message/call
Reduce the need for downtime during deployments
Effectively allows for a mix of versions between the control plane and guest agents (*in most cases) There may still be updates that will require down time
Work
- Keep track of a "version history" in comments in the code
- Update trove calls to the openstack.commom.rpc client to include a version cap param. (This is already supported in the client)
- Document the use cases and examples of how to add/modify API calls
Config
- We may need to put the version caps in the config
https://github.com/openstack/nova/blob/master/nova/baserpc.py
def __init__(self, topic): super(BaseAPI, self).__init__() target = messaging.Target(topic=topic, namespace=_NAMESPACE, version='1.0') version_cap = self.VERSION_ALIASES.get(CONF.upgrade_levels.baseapi, CONF.upgrade_levels.baseapi) self.client = rpc.get_client(target, version_cap=version_cap)
RPC calls
- We can check if the client can send a specific version
https://github.com/openstack/nova/blob/master/nova/conductor/rpcapi.py#L423