[openstack-dev] [Neutron] Common Base class for agents
Sukhdev Kapur
sukhdevkapur at gmail.com
Wed Aug 5 17:36:55 UTC 2015
Hey Kyle,
A concern was raised that this may create issue of breakages/instability in
other agents at the late stage of the release cycle - hence I proposed a
separate repo. But, if a proper due-diligence is done and the core team has
a plan to deal with this, sounds like a good plan to me.
regards.
-Sukhdev
On Wed, Aug 5, 2015 at 6:43 AM, Kyle Mestery <mestery at mestery.com> wrote:
> I definitely don't think this work should start in a new repository. As
> Sean and Andreas have said, I think the changes should be done in-tree
> rather than creating another repository for this work.
>
> On Wed, Aug 5, 2015 at 2: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
>>
>
>
> __________________________________________________________________________
> 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/6408ef41/attachment.html>
More information about the OpenStack-dev
mailing list