<div dir="ltr">Sounds good. As long as proper due-diligence is done and there are is no duplication of effort, it make sense. <div><br></div><div>Thanks</div><div>-Sukhdev</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 12:42 AM, Andreas Scheuring <span dir="ltr"><<a href="mailto:scheuran@linux.vnet.ibm.com" target="_blank">scheuran@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sukhdev,<br>
last week I spent some time to figure out the current state of modular<br>
l2 agent design and discussion. I got the impression it's not in a good<br>
shape! So I personally don't think that it makes any sense to start with<br>
a modular l2 agent prototype and in the worst case throw it all away, as<br>
we missed a single detail. I would prefer to get folks with knowledge<br>
cross all l2 agents together and work on a design first, that everyone<br>
can agree upon.<br>
<br>
So my initial mail basically was to start a effort for easily sharing<br>
code. Maybe this will end up in a single agent having multiple drivers<br>
but that's not the primary goal (which is sharing code).<br>
<br>
I'm more with Carl, to start a code sharing effort and the macvtap agent<br>
effort in parallel, independent from each other.<br>
<br>
<br>
I must admit I have less insights into ovsagent. But I know that it<br>
diverged a lot from the other agents. Sean Collins is currently<br>
evaluating an approach to bring linuxbrige closer to ovs [1]. Maybe<br>
that's the way to got. Do internal refactorings to bring things close to<br>
each other and then see what might be possible to get a common agent or<br>
at least common code.<br>
<br>
<br>
But any other suggestions are highly welcome!<br>
<br>
<br>
<br>
<br>
[1] <a href="https://review.openstack.org/#/c/208666/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/208666/</a><br>
<br>
<br>
<br>
Andreas<br>
(IRC: scheuran)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Di, 2015-08-04 at 22:42 -0700, Sukhdev Kapur wrote:<br>
> We discussed this in ML2 sub-team meeting last week and felt the best<br>
> approach is to implement this agent in a separate repo.<br>
><br>
><br>
> There is already an on-going effort/plan for modular L2 agent. This<br>
> agent would be a perfect candidate to take on that effort and<br>
> implement it for macvtap agent. Once done, this could be moved over<br>
> under neutron tent and other agents could be moved over to utilize<br>
> this framework.<br>
><br>
><br>
> Either of option 1 or 2 could be utilized to implement this agent.<br>
> Keeping it in a seperate repo keeps the it from impacting any other<br>
> agents. Once all ready and working, others could be converted over.<br>
> You get the best of both words - i.e. quick implementation of this<br>
> agent and a framework for others to use - and plenty of time to bake<br>
> the framework.<br>
><br>
><br>
> thoughts?<br>
><br>
><br>
> Sukhdev<br>
><br>
><br>
><br>
> On Mon, Aug 3, 2015 at 3:53 PM, Carl Baldwin <<a href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>><br>
> wrote:<br>
> I see this as two tasks: 1) A refactoring to share common<br>
> code and 2)<br>
> the addition of another agent following the pattern of the<br>
> others.<br>
> I'd prefer that the two tasks not be mixed in the same review<br>
> because<br>
> it makes it more difficult to review as I think Kevin eluded<br>
> to. For<br>
> me, either could be done first. I'm sure some reviewers would<br>
> prefer<br>
> that #1 be done first to avoid the proliferation of duplicated<br>
> code.<br>
> However, IMO, it is not necessary to be so strict. It can<br>
> take some<br>
> time to review common code to get it right. I'm afraid that<br>
> holding<br>
> up #2 until merging #1 will either motivate us to merge #1 too<br>
> 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<br>
> knowing that<br>
> when one of the two merges, the other will have to be rebased<br>
> to take<br>
> the other in to account. Sometimes, having the refactor in<br>
> flight can<br>
> help to allay fears about code proliferation. Actually given<br>
> Kevin's<br>
> mention of the modular agent stuff, maybe it isn't worth<br>
> putting much<br>
> effort in to the refactor patch at all.<br>
><br>
> My $0.02.<br>
><br>
> Carl<br>
><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<br>
> supporting<br>
> > macvtap attachments [1]. Kyle already decided, that this<br>
> code should<br>
> > land in the neutron tree [2]. The normal approach till now<br>
> was to copy<br>
> > an existing agent code and modify accordingly, which lead to<br>
> a lot of<br>
> > duplicated code.<br>
> ><br>
> > So my question is, how to proceed with macvtap agent? I<br>
> basically see<br>
> > the the 2 options:<br>
> ><br>
> > 1) Do it like in the past, duplicate the code that is needed<br>
> for macvtap<br>
> > agent (main loop, mechanism for detecting<br>
> new/changed/deleted devices)<br>
> > and just go for it.<br>
> ><br>
> > 2) Extract a new superclass that holds some of the common<br>
> code. This<br>
> > would work for linuxridge agent and sriovnic agent - they<br>
> could inherit<br>
> > from the new superclass and get rid of some code but they<br>
> still would<br>
> > exist on their own. OVS agent diverged too far to get it<br>
> done easily.<br>
> > (More details below)<br>
> ><br>
> ><br>
> > My personal opinion: If I had the power to decide, I would<br>
> go along with<br>
> > option #1, to get started quickly to still land my code for<br>
> liberty. But<br>
> > I would be willing to implement #2 as well, if folks think<br>
> 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>
> ><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<br>
> class<br>
> > Base class Stage 2**<br>
> > N: Step to a single agent having multiple interface drivers<br>
> (lb,<br>
> > macvtap, sriov)?<br>
> ><br>
> ><br>
> > * Stage 1: with methods that are absolutely equal along the<br>
> 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<br>
> diverged over time<br>
> > which is not just copy and paste but require some further<br>
> 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<br>
> subgroup<br>
> > but the concept is in a bad shape and needs larger<br>
> discussion. So no<br>
> > chance to start the macvtap work together with the modular<br>
> agent work.<br>
> ><br>
> > 4) Integrating it into the linuxbridge agent. A<br>
> configuration option<br>
> > would distinguish if the agent runs in linuxbridge (default)<br>
> 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>
> __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> <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>
> ><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:<br>
> <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>
><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>
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>
</div></div></blockquote></div><br></div>