Trove-rpc-versioning

Intro

This page describes the intent to implement oslo messaging's API Version Negotiation in Trove

Oslo

Oslo/Messaging#API_Version_Negotiation

Goals

Get Trove on the same page w/ other projects + oslo

1. This will require refactoring the rpc layer

Prevent backward incompatibility between Trove components

1. The rpc client can send an older version of a message/call to a newer message handler without issue
2. The rpc client can send a newer version of a message/call to an older message handler without killing it (*need to confirm this)
3. The rpc client can check to see if it can send 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

• Remove rpc common components from oslo incubator?
• Use oslo messaging library

oslo.messaging>=1.3.0

• 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)
  • Trove API --> Task Manager
  • Trove API --> Guest Agent
  • Guest Agent --> Conductor
• 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