This change adds a requirement for an "IPv6 Impact" section. In the review for Kilo priorities [1], the issue was raised around IPv6 being a priority. One outcome was the thought to ensure new features are IPv6 ready from the start. This change ensures specs have a section detailing how they affect IPv6. I've also updated approved specs with what I perceive to be their IPv6 readiness. I hope the original authors can view these to confirm what I've put in there. [1] https://review.openstack.org/#/c/136514/ Change-Id: I6b12615d5d650ea55b8e78fd43c702af8f87b3f7
6.2 KiB
Dropping rpc API compat layer
https://blueprints.launchpad.net/neutron/+spec/drop-rpc-compat
This proposal is to make more direct use of oslo.messaging APIs throughout Neutron instead of a compatibility layer based on an old API.
Problem Description
Neutron has migrated from the rpc code in oslo-incubator to the oslo.messaging library. The oslo.messaging library has a different (but better) API. To ease the transition to oslo.messaging, Neutron has used some compatibility code to convert the older style API usage to oslo.messaging APIs. This proposal is to make more direct use of oslo.messaging APIs throughout Neutron.
Moving toward more direct usage of oslo.messaging APIs will improve consistency with other projects, since all projects should be converging on the newer style APIs.
Proposed Change
The following classes are items considered as a part of the compatibility layer. The direct use of each of these things will be removed and replaced with direct use of equivalent and underlying oslo.messaging APIs.
- neutron.common.rpc.
RpcProxy RpcCallback RPCException RemoteError MessagingTimeout
This looks like a small list, but it's more invasive than it looks. It will be broken up into several iterative patches that are more easily reviewed and merged over time.
Here are some examples of the most invasive conversions (RpcProxy and RpcCallback):
from oslo import messaging
from neutron.common import rpc as n_rpc
Old style client interface using RpcProxy:
class ClientAPI(n_rpc.RpcProxy):
BASE_RPC_API_VERSION = '1.0'
def __init__(self, topic):
super(DhcpPluginApi, self).__init__(
topic=topic, default_version=self.BASE_RPC_API_VERSION)
def remote_method(self, context, arg1):
return self.call(context,
self.make_msg('remote_method',
arg1=arg1))
def remote_method_2(self, context, arg1, arg2):
return self.call(context,
self.make_msg('remote_method_2',
arg1=arg1, arg2=arg2),
version='1.1')
New style client interface:
class ClientAPI(object):
def __init__(self, topic):
target = messaging.Target(topic=topic, version='1.0')
self.client = n_rpc.get_client(target)
def remote_method(self, context, arg1):
cctxt = self.client.prepare()
return cctxt.call(context, 'remote_method', arg1=arg1)
def remote_method_2(self, context, arg1, arg2):
cctxt = self.client.prepare(version='1.1')
return cctxt.call(context, 'remote_method_2', arg1=arg1, arg2=arg2)
Old style server interface:
class ServerAPI(n_rpc.RpcCallback):
RPC_API_VERSION = '1.1'
def remote_method(self, context, arg1):
return 'foo'
def remote_method_2(self, context, arg1, arg2):
return 'bar'
New style server interface:
class ServerAPI(object):
target = messaging.Target(version='1.1')
def remote_method(self, context, arg1):
return 'foo'
def remote_method_2(self, context, arg1, arg2):
return 'bar'
Data Model Impact
None
REST API Impact
None
Security Impact
None
Notifications Impact
None
Other End User Impact
None
Performance Impact
Negligible. In theory, this is removing a compatibility layer so there should be less code, but the overall performance impact of removing the layer is negligible in the broader scope of things.
IPv6 Impact
None
Other Deployer Impact
None
Developer Impact
There are several impacts to developers. Developers used to the older rpc API (and the equivalent compatibility layers) will have to learn what's different. Arguably, it's conceptually quite similar so this shouldn't have a large impact. The oslo.messaging library itself has documentation. Looking at all of the existing code once it has been converted will help quite a bit as well, since you can just follow the existing pattern.
The other impact is patch conflicts. Since this work involves some minor refactoring across the tree, it may conflict with other code in progress. This will only occur in the case of features that modify rpc APIs. The changes will be done in a series of smaller changes, which will help with rebasing and fixing conflicts against smaller sets of updates at a time.
Community Impact
None.
Alternatives
The alternative is to leave the compatibility layer in place. The downsides of this are that Neutron's use of oslo.messaging will diverge further and further from what the rest of OpenStack messaging usage looks like. It may also make it more difficult to take advantage of new features in oslo.messaging in the future.
Implementation
Assignee(s)
- Primary assignee:
-
russellb
Work Items
The usage of each class listed in the proposed change section will be removed one at a time. The removal of each will be broken up into several changes, one per interface (rpc API).
Dependencies
- None
Testing
The unit tests will be updated as required. New ones will be added in key places where unit test coverage may be missing.
There are no functional changes here, so all of the existing unit and functional tests will be relied upon to help ensure that no regressions are introduced.
Tempest Tests
None.
Functional Tests
None.
API Tests
None.
Documentation Impact
None.
User Documentation
None.
Developer Documentation
None.
References
- Existing oslo.messaging documentation: http://docs.openstack.org/developer/oslo.messaging/