l3-agent (dis)associate floatingip only after restart

[Tino Schmeier]

Hi

We use openstack havana from the saucy repositories

After an update the neutron-l3-agent did not (dis)associate floatingips. Only after restart the service the changes are applied.

The package-version is:
neutron-l3-agent 1:2013.2.1-0ubuntu1

The neutron server sends the request to the queue:

2014-03-06 15:20:38.889 13875 DEBUG neutron.db.db_base_plugin_v2 [-] Allocated IP 212.8.XXX.X (b68d0b22-4391-4d5b-a715-344a6cd289d0/4285d8bd-b762-46b5-b839-68d07808cb73/b4618839-31ac-4c6a-a202-7514e939d0b4
) create_port /usr/lib/python2.7/dist-packages/neutron/db/db_base_plugin_v2.py:1360
2014-03-06 15:20:38.903 13875 DEBUG neutron.openstack.common.rpc.amqp [-] Sending floatingip.create.end on notifications.info notify /usr/lib/python2.7/dist-packages/neutron/openstack/common/rpc/amqp.py:59
8
2014-03-06 15:20:38.904 13875 DEBUG neutron.openstack.common.rpc.amqp [-] UNIQUE_ID is db78c1495c3c4cada5bd48a24e443298. _add_unique_id /usr/lib/python2.7/dist-packages/neutron/openstack/common/rpc/amqp.py
:339

I did not find any reference to an error in the logs of the l3-agent (debug enabled). The agent idles with:

2014-03-06 15:20:39.653 8229 DEBUG neutron.agent.l3_agent [-] Starting RPC loop for 0 updated routers _rpc_loop /usr/lib/python2.7/dist-packages/neutron/agent/l3_agent.py:686
2014-03-06 15:20:39.654 8229 DEBUG neutron.agent.l3_agent [-] RPC loop successfully completed _rpc_loop /usr/lib/python2.7/dist-packages/neutron/agent/l3_agent.py:694
2014-03-06 15:20:40.506 8229 DEBUG neutron.agent.l3_agent [-] Report state task started _report_state /usr/lib/python2.7/dist-packages/neutron/agent/l3_agent.py:794
2014-03-06 15:20:40.507 8229 DEBUG neutron.openstack.common.rpc.amqp [-] Making asynchronous cast on q-plugin... cast /usr/lib/python2.7/dist-packages/neutron/openstack/common/rpc/amqp.py:559
2014-03-06 15:20:40.508 8229 DEBUG neutron.openstack.common.rpc.amqp [-] UNIQUE_ID is f969560f298240ed842d746004840c0a. _add_unique_id /usr/lib/python2.7/dist-packages/neutron/openstack/common/rpc/amqp.py:
339
2014-03-06 15:20:40.512 8229 DEBUG amqp [-] Closed channel #1 _do_close /usr/lib/python2.7/dist-packages/amqp/channel.py:88
2014-03-06 15:20:40.513 8229 DEBUG amqp [-] using channel_id: 1 __init__ /usr/lib/python2.7/dist-packages/amqp/channel.py:70
2014-03-06 15:20:40.515 8229 DEBUG amqp [-] Channel open _open_ok /usr/lib/python2.7/dist-packages/amqp/channel.py:420
2014-03-06 15:20:40.516 8229 DEBUG neutron.agent.l3_agent [-] Report state task successfully completed _report_state /usr/lib/python2.7/dist-packages/neutron/agent/l3_agent.py:818
2014-03-06 15:20:40.653 8229 DEBUG neutron.openstack.common.lockutils [-] Got semaphore "l3-agent" for method "_rpc_loop"... inner /usr/lib/python2.7/dist-packages/neutron/openstack/common/lockutils.py:191
2014-03-06 15:20:40.653 8229 DEBUG neutron.agent.l3_agent [-] Starting RPC loop for 0 updated routers _rpc_loop /usr/lib/python2.7/dist-packages/neutron/agent/l3_agent.py:686
2014-03-06 15:20:40.654 8229 DEBUG neutron.agent.l3_agent [-] RPC loop successfully completed _rpc_loop /usr/lib/python2.7/dist-packages/neutron/agent/l3_agent.py:694

Any help would be greatly appreciated.

Tino

[Tino Schmeier (tis-x)]

Hi,

i was able to solve our problem. The neutron-plugin-vpn-agent inherits from the l3-agent !? Maybe this service also cosumes messages from the l3-agent-queues.

l3_agent <email address hidden> 1 true
l3_agent <email address hidden> 1 true
l3_agent.netnode1 <email address hidden> 2 true
l3_agent.netnode1 <email address hidden> 2 true
l3_agent_fanout_439789853af24283bdb0bab8e5d11a42 <email address hidden> 3 true
l3_agent_fanout_648459462b1c4b158f9cbd01e27452b0 <email address hidden> 3 true

I stopped the vpn-service and the (dis)association works as expected. Later i start the service and the problem did not recurred.
Now we have to look if the vpn-service works ;)

Thanks so far.

[James Page (james-page)]

Having dug into the workings of the vpn-agent for icehouse, this bug report now makes alot of sense.

The vpn-agent is a superset of the function of the l3-agent; so in effect, it provides both l3 services and vpn management.

As a result, installing both the l3-agent and vpn-agent on the same box makes no sense - they are both trying to manage the same resources.

That said, the vpn-agent relies on l3_agent.ini and potentially fwaas_driver.ini - and the associated rootwrap rules - which are provided by the l3-agent package.

I've fixed this up for icehouse under bug 1303876; I'll raise a task to resolve this for havana as well.