[openstack-dev] [Neutron] Common Base class for agents
scheuran at linux.vnet.ibm.com
Mon Aug 3 15:46:42 UTC 2015
I'm planning to add a new ml2 driver and agent to neutron supporting
macvtap attachments . Kyle already decided, that this code should
land in the neutron tree . The normal approach till now was to copy
an existing agent code and modify accordingly, which lead to a lot of
So my question is, how to proceed with macvtap agent? I basically see
the the 2 options:
1) Do it like in the past, duplicate the code that is needed for macvtap
agent (main loop, mechanism for detecting new/changed/deleted devices)
and just go for it.
2) Extract a new superclass that holds some of the common code. This
would work for linuxridge agent and sriovnic agent - they could inherit
from the new superclass and get rid of some code but they still would
exist on their own. OVS agent diverged too far to get it done easily.
(More details below)
My personal opinion: If I had the power to decide, I would go along with
option #1, to get started quickly to still land my code for liberty. But
I would be willing to implement #2 as well, if folks think this is a
Any feedback is welcome!
The ml2 driver for macvtap will stay separate.
More details to #2
A possible plan could be
Liberty: Base class Stage 1* + macvtap agent using it
Mitaka: move linuxbridge and sriovnic agent to use new base class
Base class Stage 2**
N: Step to a single agent having multiple interface drivers (lb,
* Stage 1: with methods that are absolutely equal along the 3 agents or
only require slight modifications
e.g. _setup_rpc, _report_state, _device_info_has_changes,
** Stage 2: methods that are still similar, but have diverged over time
which is not just copy and paste but require some further thinking.
e.g. treat_devices_added_updated, scan_devices, daemon_loop
Options I laid aside
3) I also discussed the modular l2 agent idea within the ml2 subgroup
but the concept is in a bad shape and needs larger discussion. So no
chance to start the macvtap work together with the modular agent work.
4) Integrating it into the linuxbridge agent. A configuration option
would distinguish if the agent runs in linuxbridge (default) or macvtap
More information about the OpenStack-dev