Open Stack

Sounds good. As long as proper due-diligence is done and there are is no
duplication of effort, it make sense.

Thanks
-Sukhdev


On Wed, Aug 5, 2015 at 12:42 AM, Andreas Scheuring <
scheuran at linux.vnet.ibm.com> wrote:

> 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)
>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150805/9af97c7b/attachment.html>