bagpipe: do not overload the ovs agent
Bug #1492021 reported by
Mathieu Rohon
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
networking-bgpvpn |
Fix Released
|
High
|
Thomas Morin | ||
neutron |
Invalid
|
Undecided
|
Unassigned |
Bug Description
the bagpipe driver works with its own agent that is an overload of the ovs agent.
with the neutron liberty release, the ovs agent is extendable, thanks to this change :
https:/
bagpipe should be able to leverage this extension framework to avoid the use of its own l2 ovs agent.
Changed in bgpvpn: | |
importance: | Undecided → High |
tags: | added: bagpipe |
Changed in bgpvpn: | |
assignee: | Thomas Morin (tmmorin-orange) → Mathieu Rohon (mathieu-rohon) |
Changed in bgpvpn: | |
assignee: | Mathieu Rohon (mathieu-rohon) → Thomas Morin (tmmorin-orange) |
Changed in neutron: | |
status: | Incomplete → Invalid |
To post a comment you must log in.
I've started to look at how to do this.
It seems that using an agent extension to register BGPVPN rpcs and route them to the right methods would work, and would be quite easy. That would allow to move the RPC definitions from networking- bagpipe- l2 to networking-bgpvpn, which is good.
However, to setup the br-tun/ br-int/ br-mpls dataplane, we would need to access to things that are internal to the OVS driver and not (yet) exposed to agent extension. Examples are: names of bridges, method to setup an ARP entry and local_vlan_map. Unless we modify the agent extension framework, I don't think we will be able to fully do things with an agent extension.
( We could possibly avoid overloading the OVS agent class in the following way: use our own main to instantiate the ovsagent ourselves and obtain access to its internal variables/methods, but that wouldn't be cleaner)