In the networking-bgpvpn project, the reference driver interacts with the openvswitch agent (of the ML2 openvswitch mech driver) with new RPCs to allow setup exchanging information with the BGP VPN implementation running on the compute nodes. We also need the OVS agent to setup specific things between the bridges for MPLS traffic.
To extend the agent behavior, we currently create a new agent by mimicking the main() in ovs_neutron_agent.py with a main() instantiating a class that overloads the OVSAgent class with the additional behavior we need [1].
This is really not the ideal way of extending the agent and we would prefer using the L2 agent extension framework [2].
This approach works, but only partially: we are able to register our RPC consumers, but are missing access to some datastructures of the agent that we need to use (setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge objects to manipulate OVS ports).
Copying my response from the ML thread:
We don't want to give extensions direct access to the agent object or else we will run the risk of breaking extensions all of the time during any kind of agent reorganization or refactoring. Having a well defined API in between will give us flexibility to move things around.