[openstack-dev] [Neutron] Common Base class for agents
Kevin Benton
blak111 at gmail.com
Wed Aug 5 17:57:36 UTC 2015
Well we can always develop the new framework and wait until the start of
the next cycle to swap over the existing agents if it doesn't look stable
enough.
On Wed, Aug 5, 2015 at 1:36 PM, Sukhdev Kapur <sukhdevkapur at gmail.com>
wrote:
> 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
>>
>>
>
> __________________________________________________________________________
> 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/20150805/5e58273f/attachment.html>
More information about the OpenStack-dev
mailing list