[SR-IOV] --no-qos-policy for network does not clean applied limits for ports

[Ann Taraday]

When remove qos-policy from network limits on SR-IOV ports are not cleared - http://paste.openstack.org/show/608964/ . There are no errors in logs.
If we launch another new port in this network no qos rule will apply to it, but existing one can be cleared only manually.
If the same qos policy applied for the port directly with --no-qos-policy it is cleared.

Reproduced on the stable/newton.

Ubuntu 16.04.
Ethernet controller: Intel Corporation 82599ES 10-Gigabit
Kernel driver in use: ixgbe

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello @Ann:

I've tested this scenario with one host as compute and controller node. Steps:
- Added a SR-IOV port
- Added a new VM with this port
- Added a qos policy with a max-bw rule
- Set the qos policy in the port network
  - The VF rate is set
- Unset (using neutron client and openstack client) the qos policy in the network
  - The VF rate is unset [1]

Also I executed the sriov nic agent in debug node, using breakpoints. I can see in both updates (set and unset qos policy) the trigger function "network_update" [2] is called and "self.agent.updated_devices" is set with the list of ports of this network (in this case only one)

Please, can you check in sriov nic agent logs if the command deleting the rate [1] is executed?

[1] 2017-05-10 17:16:44.817 DEBUG neutron.agent.linux.utils [req-c0e15b2b-2c69-4f9b-ae87-05318dd8bddf None None] Running command (rootwrap daemon): ['ip', 'link', 'set', 'enp6s0f1', 'vf', '1', 'rate', '0'] from (pid=14833) execute_rootwrap_daemon /opt/stack/neutron/neutron/agent/linux/utils.py:108

[2] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py#L99

[Ann Taraday (akamyshnikova)]

This is interesting, following your steps I got qos rule cleared http://paste.openstack.org/show/609645/ and got the debug message in logs as you mentioned.
But after I created port, attached qos-policy for network and created vm from this port http://paste.openstack.org/show/609645/ and there I got it not cleared.
If I apply policy then create port and vm it also works.
Do we have any limitations that vm should be created from port immediately?

[Ann Taraday (akamyshnikova)]

Checked on the devstack with stable/ocata got the same results - qos rule for network is not cleared. http://paste.openstack.org/show/609807/

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello Ann:

I can't reproduce this bug. In [1] you have the list of commands executed. In [2] you have the status of the VFs in three different stages:
- When the system is stacked.
- Once the VM is started and the QoS policy (and rule) is applied to the port.
- When the QoS policy is removed from the network.

Sorry, I don't know how to continue testing this bug.

[1] http://paste.openstack.org/show/609870/
[2] http://paste.openstack.org/show/609869/

[Ann Taraday (akamyshnikova)]

I debug this issue today.
Here are some logs http://paste.openstack.org/show/609902/

And it shows the following result:
qos_policy_id for network is not getting updated, so need_network_update_notify is False https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L856 - http://paste.openstack.org/show/609903/, some more http://paste.openstack.org/show/609907/ - get_network gets stale info.

So, it seems I hit https://bugs.launchpad.net/neutron/+bug/1649503. So, we need to backport this one.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Ok, next time I'll read more carefully the bug. You were testing in stable/newton...