Metering doesn't work for DVR routers on compute nodes

Bug #1807157 reported by Alexandru Sorodoc
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
neutron
In Progress
Undecided
Alexandru Sorodoc

Bug Description

The metering agent running on compute nodes fails to report metering data for DVR routers.

How to reproduce:
1. Have a multi-node OpenStack Pike deployment with a network node and a compute node (alongside other nodes needed).
2. Create a distributed public router and attach it to a private network.
3. Create some metering rules. In my case I have a metering label with the ingress rule 0.0.0.0/0 and another metering label with the egress rule 0.0.0.0/0.
3. Create an instance attached to the private network. You can optionally associate a floating ip with it.
4. Do something on the instance that would generate external traffic. For example, download a file.
5. Check the metering samples for the metering rules in gnocchi. The traffic generated by the instance is not recorded. You can also ssh into the compute and network nodes and check the iptables rules with the argument -v on the qrouter- and snat- namespaces for the public router. You can see the traffic on the snat- namespace on the network node when not using a floating ip and on the qrouter- namespace on the compute node when using a floating ip. However, the metering labels are missing.

Checking the code in `neutron/services/metering/drivers/iptables/iptables_driver.py` I noticed the following:

1. The metering agent adds the metering iptables rules on the qrouter- namespace for the qg- interface. This is for centralized routers and works well.
2. The metering agent adds the metering iptables rules on the snat- namespace for the rpf- interface. This is wrong. The snat- namespace (which exists only on network nodes for DVR routers) houses a qg- interface for doing NAT. The rfp- interface exists only on compute nodes in the qrouter- namespace and it is used to route floating ip traffic.
3. The metering agent adds the metering rules only once for the qrouter- namespace. It uses the RouterWithMetering.metering_labels dictionary to avoid adding the same metering label twice in iptables. But it uses the dictionary for both the qrouter- and the snat- namespaces. When a label is added to the qrouter- namespace it will not be added to the snat- namespace too because it will already be present in the dictionary.

Also, in `neutron/db/metering/metering_rpc.py` the `get_sync_data_metering` function doesn't include DVR routers for compute node hosts. The l3_plugin.get_l3_agents function in Pike seems to only return the scheduled routers on the host (which doesn't include DVR routers).

The metering agent code has not changed significantly since stable/pike, so I assume that the problem still persists.

Revision history for this message
Alexandru Sorodoc (bno1) wrote :

I crated a change for this: https://review.openstack.org/#/c/621165/ and it seems to fix the issue on our Pike deployment.

description: updated
Alexandru Sorodoc (bno1)
tags: added: metering
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/634016

Changed in neutron:
assignee: nobody → Mohamed El Gindi (gindi)
status: New → In Progress
Revision history for this message
Slawek Kaplonski (slaweq) wrote : auto-abandon-script

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

Changed in neutron:
assignee: Mohamed El Gindi (gindi) → nobody
status: In Progress → New
tags: added: timeout-abandon
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.openstack.org/634016
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.opendev.org/666969

Changed in neutron:
assignee: nobody → Alexandru Sorodoc (bno1)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by "Rodolfo Alonso <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/666969

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Change abandoned by "Rodolfo Alonso <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/666966
Reason: This patch has been abandoned due to the lack of activity. Please propose it again if needed. Thanks!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Change abandoned by "Rodolfo Alonso <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/666968
Reason: This patch has been abandoned due to the lack of activity. Please propose it again if needed. Thanks!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Change abandoned by "Rodolfo Alonso <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/666965
Reason: This patch has been abandoned due to the lack of activity. Please propose it again if needed. Thanks!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Change abandoned by "Rodolfo Alonso <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/666964
Reason: This patch has been abandoned due to the lack of activity. Please propose it again if needed. Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.