Sukhdev, last week I spent some time to figure out the current state of modular l2 agent design and discussion. I got the impression it's not in a good shape! So I personally don't think that it makes any sense to start with a modular l2 agent prototype and in the worst case throw it all away, as we missed a single detail. I would prefer to get folks with knowledge cross all l2 agents together and work on a design first, that everyone can agree upon.
So my initial mail basically was to start a effort for easily sharing code. Maybe this will end up in a single agent having multiple drivers but that's not the primary goal (which is sharing code). I'm more with Carl, to start a code sharing effort and the macvtap agent effort in parallel, independent from each other. I must admit I have less insights into ovsagent. But I know that it diverged a lot from the other agents. Sean Collins is currently evaluating an approach to bring linuxbrige closer to ovs [1]. Maybe that's the way to got. Do internal refactorings to bring things close to each other and then see what might be possible to get a common agent or at least common code. But any other suggestions are highly welcome! [1] https://review.openstack.org/#/c/208666/ Andreas (IRC: scheuran) On Di, 2015-08-04 at 22:42 -0700, 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? > > > Sukhdev > > > > On Mon, Aug 3, 2015 at 3:53 PM, Carl Baldwin <[email protected]> > wrote: > I see this as two tasks: 1) A refactoring to share common > code and 2) > the addition of another agent following the pattern of the > others. > I'd prefer that the two tasks not be mixed in the same review > because > it makes it more difficult to review as I think Kevin eluded > to. For > me, either could be done first. I'm sure some reviewers would > prefer > that #1 be done first to avoid the proliferation of duplicated > code. > However, IMO, it is not necessary to be so strict. It can > take some > time to review common code to get it right. I'm afraid that > holding > up #2 until merging #1 will either motivate us to merge #1 too > hastily > and do a poor job or hold up #2 longer than it should be. > > If this were me, I would post both as independent reviews > knowing that > when one of the two merges, the other will have to be rebased > to take > the other in to account. Sometimes, having the refactor in > flight can > help to allay fears about code proliferation. Actually given > Kevin's > mention of the modular agent stuff, maybe it isn't worth > putting much > effort in to the refactor patch at all. > > My $0.02. > > Carl > > On Mon, Aug 3, 2015 at 9:46 AM, Andreas Scheuring > <[email protected]> wrote: > > Hi, > > I'm planning to add a new ml2 driver and agent to neutron > supporting > > macvtap attachments [1]. Kyle already decided, that this > code should > > land in the neutron tree [2]. The normal approach till now > was to copy > > an existing agent code and modify accordingly, which lead to > a lot of > > duplicated code. > > > > 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 > > good idea. > > > > > > > > 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, > > macvtap, sriov)? > > > > > > * 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, > > _process_network_devices > > > > ** 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 > > mode. > > > > > > [1] https://bugs.launchpad.net/neutron/+bug/1480979 > > [2] https://review.openstack.org/#/c/195907/ > > > > > > -- > > Andreas > > (IRC: scheuran) > > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andreas (IRC: scheuran) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
