Sounds good. As long as proper due-diligence is done and there are is no duplication of effort, it make sense.
Thanks -Sukhdev On Wed, Aug 5, 2015 at 12:42 AM, Andreas Scheuring < [email protected]> wrote: > 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 >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
