<div dir="ltr">We discussed this in ML2 sub-team meeting last week and felt the best approach is to implement this agent in a separate repo.<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>thoughts? </div><div><br></div><div>Sukhdev</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 3:53 PM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see this as two tasks:  1) A refactoring to share common code and 2)<br>
the addition of another agent following the pattern of the others.<br>
I'd prefer that the two tasks not be mixed in the same review because<br>
it makes it more difficult to review as I think Kevin eluded to.  For<br>
me, either could be done first.  I'm sure some reviewers would prefer<br>
that #1 be done first to avoid the proliferation of duplicated code.<br>
However, IMO, it is not necessary to be so strict.  It can take some<br>
time to review common code to get it right.  I'm afraid that holding<br>
up #2 until merging #1 will either motivate us to merge #1 too hastily<br>
and do a poor job or hold up #2 longer than it should be.<br>
<br>
If this were me, I would post both as independent reviews knowing that<br>
when one of the two merges, the other will have to be rebased to take<br>
the other in to account.  Sometimes, having the refactor in flight can<br>
help to allay fears about code proliferation.  Actually given Kevin's<br>
mention of the modular agent stuff, maybe it isn't worth putting much<br>
effort in to the refactor patch at all.<br>
<br>
My $0.02.<br>
<span class="HOEnZb"><font color="#888888"><br>
Carl<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Aug 3, 2015 at 9:46 AM, Andreas Scheuring<br>
<<a href="mailto:scheuran@linux.vnet.ibm.com">scheuran@linux.vnet.ibm.com</a>> wrote:<br>
> Hi,<br>
> I'm planning to add a new ml2 driver and agent to neutron supporting<br>
> macvtap attachments [1]. Kyle already decided, that this code should<br>
> land in the neutron tree [2]. The normal approach till now was to copy<br>
> an existing agent code and modify accordingly, which lead to a lot of<br>
> duplicated code.<br>
><br>
> So my question is, how to proceed with macvtap agent? I basically see<br>
> the the 2 options:<br>
><br>
> 1) Do it like in the past, duplicate the code that is needed for macvtap<br>
> agent (main loop, mechanism for detecting new/changed/deleted devices)<br>
> and just go for it.<br>
><br>
> 2) Extract a new superclass that holds some of the common code. This<br>
> would work for linuxridge agent and sriovnic agent - they could inherit<br>
> from the new superclass and get rid of some code but they still would<br>
> exist on their own. OVS agent diverged too far to get it done easily.<br>
> (More details below)<br>
><br>
><br>
> My personal opinion: If I had the power to decide, I would go along with<br>
> option #1, to get started quickly to still land my code for liberty. But<br>
> I would be willing to implement #2 as well, if folks think this is a<br>
> good idea.<br>
><br>
><br>
><br>
> Any feedback is welcome!<br>
><br>
><br>
> The ml2 driver for macvtap will stay separate.<br>
><br>
><br>
> ---------------------------------------------------------------<br>
><br>
><br>
> More details to #2<br>
> A possible plan could be<br>
> Liberty: Base class Stage 1* + macvtap agent using it<br>
> Mitaka: move linuxbridge and sriovnic agent to use new base class<br>
>         Base class Stage 2**<br>
> N: Step to a single agent having multiple interface drivers (lb,<br>
> macvtap, sriov)?<br>
><br>
><br>
> * Stage 1: with methods that are absolutely equal along the 3 agents or<br>
> only require slight modifications<br>
> e.g. _setup_rpc, _report_state, _device_info_has_changes,<br>
> _process_network_devices<br>
><br>
> ** Stage 2: methods that are still similar, but have diverged over time<br>
> which is not just copy and paste but require some further thinking.<br>
> e.g. treat_devices_added_updated, scan_devices, daemon_loop<br>
><br>
><br>
> Options I laid aside<br>
> 3) I also discussed the modular l2 agent idea within the ml2 subgroup<br>
> but the concept is in a bad shape and needs larger discussion. So no<br>
> chance to start the macvtap work together with the modular agent work.<br>
><br>
> 4) Integrating it into the linuxbridge agent. A configuration option<br>
> would distinguish if the agent runs in linuxbridge (default) or macvtap<br>
> mode.<br>
><br>
><br>
> [1] <a href="https://bugs.launchpad.net/neutron/+bug/1480979" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1480979</a><br>
> [2] <a href="https://review.openstack.org/#/c/195907/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/195907/</a><br>
><br>
><br>
> --<br>
> Andreas<br>
> (IRC: scheuran)<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>