[qos]set running vms ingress-bandwidth-limit, then delete running vm,but ovs queue is still residual

Bug #1726732 reported by Zachary Ma
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Zachary Ma

Bug Description

1.create vm:
[root@172e18e211e96 ~]# nova interface-list mzx4
+------------+--------------------------------------+--------------------------------------+--------------+-------------------+
| Port State | Port ID | Net ID | IP addresses | MAC Addr |
+------------+--------------------------------------+--------------------------------------+--------------+-------------------+
| ACTIVE | f4ae0545-ca86-40c5-b2f7-064e521f13db | 1464fb8c-3879-4e2a-9833-3aa0882285d5 | 5.5.5.11 | fa:16:3e:57:cb:ba |
+------------+--------------------------------------+--------------------------------------+--------------+-------------------+
2. Set the policy on the port.
[root@172e18e211e96 ~]# openstack port set --qos-policy bw-limiter f4ae0545-ca86-40c5-b2f7-064e521f13db

and check ovs by cmd:
[root@172e18e211e9 ~]# ovs-vsctl list queue
_uuid : 1e4f2c2d-4116-4484-8eb6-5b13d9de649f
dscp : []
external_ids : {id="tapf4ae0545-ca", queue_type="0"}
other_config : {burst="10000000", max-rate="100000000"}

3.then delete vm in running status,and check ovs again:
[root@172e18e211e9 ~]# ovs-vsctl list queue
_uuid : 1e4f2c2d-4116-4484-8eb6-5b13d9de649f
dscp : []
external_ids : {id="tapf4ae0545-ca", queue_type="0"}
other_config : {burst="10000000", max-rate="100000000"}

tapf4ae0545-ca has been removed in ovs, but ovs queue is still residual!!

Zachary Ma (mazengxie)
summary: - [qos]configure running vms ingress-bandwidth-limit, then delete running
- vm,but ovs queue is still residual
+ [qos]set running vms ingress-bandwidth-limit, then delete running vm,but
+ ovs queue is still residual
Changed in neutron:
assignee: nobody → Slawek Kaplonski (slaweq)
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

I can confirm that both qos and queue is not removed from ovs in such case

Changed in neutron:
status: New → Confirmed
importance: Undecided → Medium
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/515055

Changed in neutron:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Changed in neutron:
assignee: Slawek Kaplonski (slaweq) → Zachary Ma (mazengxie)
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/515055
Reason: Better solution IMHO was proposed in https://review.openstack.org/#/c/515566/

Changed in neutron:
assignee: Zachary Ma (mazengxie) → Slawek Kaplonski (slaweq)
Changed in neutron:
assignee: Slawek Kaplonski (slaweq) → Zachary Ma (mazengxie)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/pike)

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/525888

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

Reviewed: https://review.openstack.org/515566
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ee423e1fa035146904eb8cdd78660cf1cafa64e8
Submitter: Zuul
Branch: master

commit ee423e1fa035146904eb8cdd78660cf1cafa64e8
Author: Zachary <mazengxie@126.com>
Date: Fri Oct 27 10:13:58 2017 +0800

    [Qos] Fix residues of ovs in ingress bw limit

    When we delete vm port with attached QoS policy,
    it is just doing nothing if vif_port does not exist.

    This is fine for egress bandwidth limit as it is configured
    directly on vif_port in OVS.

    For ingress bw limit however it uses additional records in
    Openvswitch database: qos and queue. Those records are not
    cleaned up in such case.

    This patch also records port in self.ports in the case of
    bandwidth limit rules, just as in the case of dscp rules.
    Never execute port clear if vif_port not exists. Finally, ovs
    driver can clean such qos and queue records

    Change-Id: Iddeb49e1e6538a178ca468df0fdf9e0617ca4f1c
    Closes-Bug: #1726732

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 12.0.0.0b2

This issue was fixed in the openstack/neutron 12.0.0.0b2 development milestone.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/pike)

Reviewed: https://review.openstack.org/525888
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=40a811bea47e02c403e20150cb31de1be952db1e
Submitter: Zuul
Branch: stable/pike

commit 40a811bea47e02c403e20150cb31de1be952db1e
Author: Zachary <mazengxie@126.com>
Date: Fri Oct 27 10:13:58 2017 +0800

    [Qos] Fix residues of ovs in ingress bw limit

    When we delete vm port with attached QoS policy,
    it is just doing nothing if vif_port does not exist.

    This is fine for egress bandwidth limit as it is configured
    directly on vif_port in OVS.

    For ingress bw limit however it uses additional records in
    Openvswitch database: qos and queue. Those records are not
    cleaned up in such case.

    This patch also records port in self.ports in the case of
    bandwidth limit rules, just as in the case of dscp rules.
    Never execute port clear if vif_port not exists. Finally, ovs
    driver can clean such qos and queue records

    Change-Id: Iddeb49e1e6538a178ca468df0fdf9e0617ca4f1c
    Closes-Bug: #1726732
    (cherry picked from commit ee423e1fa035146904eb8cdd78660cf1cafa64e8)

tags: added: in-stable-pike
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 11.0.3

This issue was fixed in the openstack/neutron 11.0.3 release.

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.