Hey Kyle, A concern was raised that this may create issue of breakages/instability in other agents at the late stage of the release cycle - hence I proposed a separate repo. But, if a proper due-diligence is done and the core team has a plan to deal with this, sounds like a good plan to me.
regards. -Sukhdev On Wed, Aug 5, 2015 at 6:43 AM, Kyle Mestery <[email protected]> wrote: > I definitely don't think this work should start in a new repository. As > Sean and Andreas have said, I think the changes should be done in-tree > rather than creating another repository for this work. > > On Wed, Aug 5, 2015 at 2: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 > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
