Open Stack

I would just de-dup anything that is obvious into a common class to inherit
from. Don't go through any major re-factorings because that will just take
longer to review and will probably need to be reworked anyway when we spend
more time on the modular agent stuff later in the cycle.

On Mon, Aug 3, 2015 at 8: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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150803/056b93ef/attachment.html>