Open Stack

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 <carl at ecbaldwin.net>
> 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
>         <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
>         
>         __________________________________________________________________________
>         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
>         
> 
> 
> __________________________________________________________________________
> 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

-- 
Andreas
(IRC: scheuran)