An L2 agent extension can't access agent methods

Bug #1499637 reported by Thomas Morin on 2015-09-25
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Unassigned

Bug Description

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).

Tags: rfe Edit Tag help
description: updated
Kevin Benton (kevinbenton) wrote :

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.

Changed in neutron:
status: New → Confirmed
Changed in neutron:
importance: Undecided → Wishlist

Can we track this within the bug 1517903's initiative?

Thomas Morin (tmmorin-orange) wrote :

Armax, yes, bug 1517903 extends the discussion beyond the particular case of networking-bgpvpn, that makes sense.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers