Neutron advanced services (*aaS) projects sometimes need access to resources internal to the L3 agent. For example, FWaaS needs:
Currently, the accepted methodology is inheritance: the L3NATAgent inherits from the advanced service. Only those extensions whose classes are inherited from L3NATAgent have access to agent resources like router and namespace data. This has several drawbacks:
To address these problems, we will decouple these services from the agent, so that each *aaS is a separate extension that registers with the extension manager and provides the extension manager a list of RPC messages it wishes to consume, and handler functions to process those RPC messages. The extension manager will register each RPC message type with neutron’s callback registry as a consumer and will use the existing RPC callback producer pattern to listen for notifications about events of interest. When an RPC callback occurs, each extension that registered to handle that type of RPC message will have its handler function invoked. Multiple *aaS services will be able to plug in simultaneously without interfering with each other. Vendor-specific extensions can be written as agent extension drivers.
This proposal will create the following new objects in the L3 agent:
This mechanism will be similar to the extension system implemented for the L2 agent in http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l2/extensions/manager.py?id=4821196f94d333cb4c310601776f9b2319a6ddf0 . To the maximum extent possible, generalizable code will be moved to a common location so that both the L2 and L3 agent can re-use it.
This implementation is patterned upon the implementation for the QoS agent extension in the L2 agent and the accompanying L2 notification driver on the neutron server. This section describes that interaction with pointers to code (stable/mitaka branch). Examples of agent specifics are provided in the context of the neutron-openvswitch-agent.
The implementation in neutron-server flows thusly:
The neutron-openvswitch-agent implements the flows thusly:
The idea to simply use and adapt the existing L2 implementation to handle L3 communications also was considered and rejected. The QoS notification mechanism needs to remain specific to port and network updates in order not to crush the message queue.
The notifications proposed in this spec will override certain existing notifications but should not dramatically increase the number of notifications.
Server- and agent-side configuration changes must be made. For instance, for FWaaS:
This change introduces a standardized interface for developing advanced services on top of the L3 agent, and thus eases adoption of new L3 advanced services and facilitates developer experimentation.
This change expands the stability and standardization of extension hooks into neutron, making the platform even more friendly to new technologies and vendors.
Functional tests would need to verify that the L3AgentExtensionManager is loading the L3AgentExtension, as well as testing the communications of the notification driver.
Fullstack tests would need to exist to enable loading of a dummy extension and then ensuring that the dummy extension receives RPC calls properly when issued by Neutron server.
Existing user documentation describing services that make use of the L3 agent facility, for example the _Admin Guide’s “Introduction to Networking” section <http://docs.openstack.org/admin-guide/networking_introduction.html>_ would need to be updated.
New developer documentation describing the L3 agent extension mechanism would need to be created.
Documentation of the method to discover what extensions are active would need to be created.