Open Stack

On Wed, Aug 05, 2015 at 01:42:20AM EDT, Sukhdev Kapur wrote:
> We discussed this in ML2 sub-team meeting last week and felt the best
> approach is to implement this agent in a separate repo.
> 
> There is already an on-going effort/plan for modular L2 agent. This agent
> would be a perfect candidate to take on that effort and implement it for
> macvtap agent. Once done, this could be moved over under neutron tent and
> other agents could be moved over to utilize this framework.
> 
> Either of option 1 or 2 could be utilized to implement this agent. Keeping
> it in a seperate repo keeps the it from impacting any other agents. Once
> all ready and working, others could be converted over. You get the best of
> both words - i.e. quick implementation of this agent and a framework for
> others to use - and plenty of time to bake the framework.
> 
> thoughts?

I'm eyeballing the changes[0] that macvtap makes to the Linux Bridge
agent. I think that the LB agent can be refactored a bit to make the
changes less intrusive and allow macvtap to have classes the main Linux
Bridge agent can load - that will encapsulate the functionality.

For example I like the idea of renaming LinuxBridgeManager[1] to
LinuxNetworkManager, and the subsequent MacvtapManager class - if we can
re-work a LinuxBridgeManager class that contains all the bridge handling
functions, as a subclass of LinuxNetworkManager, that would maybe pave
the way for macvtap and the existing LB code to co-exist nicely.
Eventually it could develop into a good API for handling all the
different ways to do l2 agent plugging.

[0]: https://github.com/scheuran/networking-macvtap/commit/36a068cf3d3d6930ab9330efb099cd95a84ca785
[1]: https://github.com/scheuran/networking-macvtap/commit/36a068cf3d3d6930ab9330efb099cd95a84ca785#diff-0445dd61b516b3357ecf54d6e4609e0fR76

-- 
Sean M. Collins