Open Stack

Hi Doug.

The old and new MROs are both pretty complicated, and it’s not entirely clear to me yet why the original one worked. (The MROs are included below for reading pleasure; they're embellished to show the incoming args to self’s init and outgoing args to super’s init in each case.)

I’m fairly sure the APIs for the mixins can be made the same, and I’ll try that.  But I still wonder if in fact the problem is a base class ordering issue.

The error that 223343 produced occurs in method call #6 in the "AFTER" MRO, where we get the following trace:

	super(PeriodicTasks, self).__init__()
TypeError: __init__() takes exactly 2 arguments (1 given)


For grins, we changed PeriodicTasks’s call to super init as suggested by the trace:

	super(PeriodicTasks, self).__init__(conf)


At this point FWaaSAgentRpcCallbackMixin (AFTER, #8) complained:

	super(FWaaSAgentRpcCallbackMixin, self).__init__(host)
TypeError: object.__init__() takes no parameters


Changing *that* class as suggested elicited the following (to me baffling) result:

	super(FWaaSAgentRpcCallbackMixin, self).__init__()
TypeError: __init__() takes exactly 2 arguments (1 given)


I find it baffling because FWaaSAgentRpcCallbackMixin is the end of the line, it’s a subclass of object, and object doesn’t allow arguments to init (so whose init is that? that’s the next thing I’m going to look at).  (It’s for these same reasons that I don’t understand why things worked before the 223343 change.)

I’m still looking at things.  (And learning about MRO, which I’ve never really dealt with before.)  Will run pdb and see what surfaces.

Thanks for your help.  Thoughts, comments, suggestions all welcome.
Margaret


BEFORE 223343
 1. varmour_router_vArmourL3NATAgent 		(host, conf)-->(host, conf)
 2. agent_L3NATAgent 				(host, conf)-->(conf)
 3. firewall_l3_agent_FWaaSL3AgentRpcCallback 	(conf)-->(host)
 4. api_FWaaSAgentRpcCallbackMixin 		(host)-->(host)
 5. ha_AgentMixin				(host)-->(host)
 6. dvr_AgentMixin				(host)-->(host)
 7. manager_Manager				(host)-->(conf)
 8. periodic_task_PeriodicTasks			(conf)-->()
 9. firewall_l3_agent_FWaaSL3AgentRpcCallback	(conf)-->(host)
10. api_FWaaSAgentRpcCallbackMixin		(host)-->(host)
11. object

AFTER 223343
 1. varmour_router_vArmourL3NATAgent 		(host, conf)-->(host, conf)
 2. agent_L3NATAgent 				(host, conf)-->(host)
 3. ha_AgentMixin				(host)-->(host)
 4. dvr_AgentMixin				(host)-->(host)
 5. manager_Manager				(host)-->(conf)
 6. periodic_task_PeriodicTasks			(conf)-->()
 7. firewall_l3_agent_FWaaSL3AgentRpcCallback 	(conf)-->(host)
 8. api_FWaaSAgentRpcCallbackMixin		(host)-->(host)
 9. object

--
Margaret Frances
Eng 4, Prodt Dev Engineering



> On May 5, 2016, at 7:06 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> 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
> 
> __________________________________________________________________________
> 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/20160506/8e3b177e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160506/8e3b177e/attachment.pgp>