Open Stack

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
<scheuran at linux.vnet.ibm.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev