Merge "Drop usage of rpc compat layer"

This commit is contained in:
Jenkins 2014-11-13 17:21:41 +00:00 committed by Gerrit Code Review
commit 84461d1d95
1 changed files with 254 additions and 0 deletions

View File

@ -0,0 +1,254 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=============================
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.
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/