Open Stack

Excerpts from Nate Johnston's message of 2016-05-05 17:40:13 -0400:
> FWaaS team,
> 
> After a day of looking at the tests currently failing in the FWaaS repo, I
> believe I have the issue narrowed down considerably. First, to restate what
> is going on.  If you check out the neutron-fwaas repository and run `tox -e
> py27` in it, you will get six errors all in the
> neutron_fwaas.tests.unit.services.firewall.agents.varmour.test_varmour_router.TestVarmourRouter
> section.
> Running the py34 tests results in similar problems.  The failures follow
> the following form:
> 
> Captured traceback:
> 
> ~~~~~~~~~~~~~~~~~~~
> 
>     Traceback (most recent call last):
> 
>       File
> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
> line 190, in test_agent_external_gateway
> 
>         router = self._create_router()
> 
>       File
> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
> line 87, in _create_router
> 
>         router = varmour_router.vArmourL3NATAgent(HOSTNAME, self.conf)
> 
>       File
> "neutron_fwaas/services/firewall/agents/varmour/varmour_router.py", line
> 54, in __init__
> 
>         super(vArmourL3NATAgent, self).__init__(host, conf)
> 
>       File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/agent.py",
> line 244, in __init__
> 
>         super(L3NATAgent, self).__init__(host=self.conf.host)
> 
>       File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/ha.py",
> line 93, in __init__
> 
>         super(AgentMixin, self).__init__(host)
> 
>       File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/dvr.py",
> line 30, in __init__
> 
>         super(AgentMixin, self).__init__(host)
> 
>       File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/agent.py",
> line 70, in __init__
> 
>         super(FWaaSAgentRpcCallbackMixin, self).__init__(host)
> 
>       File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/manager.py",
> line 44, in __init__
> 
>         super(Manager, self).__init__(conf)
> 
>       File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/lib/python2.7/site-packages/oslo_service/periodic_task.py",
> line 177, in __init__
> 
>         super(PeriodicTasks, self).__init__()
> 
>     TypeError: __init__() takes exactly 2 arguments (1 given)
> 
> I pinged the Oslo folks, and they were able to help me look into the issue,
> which cleared oslo.service of any role.  The change that introduced this is
> actually a neutron change - https://review.openstack.org/#/c/223343/ - and
> I could experimentally test for it by doing the following, which checks out
> the change before the problem one, "Remove BGP code from neutron".  At that
> point `tox -e py27` could complete successfully.
> 
> Everything works with the older commit:   cd .tox/py27/src/neutron && git
> checkout fe702f8f2af265554c7ff6f464b99562f8c54254 && cd - && tox -e py27
> Things break with commit 223343:          cd .tox/py27/src/neutron && git
> checkout f31861843d90e013d31fb76fc576b49a35e218aa4  && cd - && tox -e py27
> 
> My guess on this is that the reason for the breakage is due to multiple
> inheritance and the changing of the ancestry for the L3NATAgent object.  So
> the focus of my effort (with Margaret Frances providing crucial insight) is
> determining what precisely needs to be fixed or reverted to make this work,
> while in keeping with the removal of FWaaS code from Neutron.  I shall
> continue to look at this tomorrow, but if anyone wishes to pick up the
> torch and figure this out then you should feel free to do so.  If not, I
> shall resume tomorrow.
> 
> Thanks,
> 
> --N.

Based on looking at the class hierarchy for vArmourL3NATAgent, I think
the problem is that the mixin classes up and down that hierarchy don't
take the same arguments for __init__(). That's going to make using super()
difficult. Normally one would just need to switch the order of the base
classes so all of the mixins are initialized before the Manager and
PeriodicTask base classes, but doing that doesn't fix the problem in
this case.

Is it possible to make all of the mixin APIs the same?

Doug