[QoS] QoS policy doesn't update rule after recreating net,route,instance and applying existing rule

Bug #1580985 reported by Sergii
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Status tracked in 10.0.x
10.0.x
Fix Committed
High
Ilya Chukhnakov
9.x
Fix Released
High
Ilya Chukhnakov

Bug Description

Detailed bug description:

When I create router, net, VMs, policy and bandwidth rule and applying it on port - it is works correctly. But, when VMs, router, net was deleted and recreated - after applying policy on new just created port and updating bandwidth-limit-rule it is have no effect and speed is equal to bandwidth that was before updating.

Steps to reproduce:

1. neutron net-create net01
2. neutron subnet-create net01 192.168.112.0/24 --name subnet01
3. neutron router-create router01
4. neutron router-interface-add router01 subnet01
5. neutron router-interface-add router01 admin_floating_net__subnet
6. Net_ID=`neutron net-list | grep net01 | awk '{print $2}'`

7. nova boot --flavor m1.medium --image Ubuntu_14.04_iperf_nload --availability-zone nova:node- 2.domain.tld --key-name CloudKey --nic net-id=$Net_ID Ubuntu-1

8. nova boot --flavor m1.medium --image Ubuntu_14.04_iperf_nload --availability-zone nova:node-3.domain.tld --key-name CloudKey --nic net-id=$Net_ID Ubuntu-2

9. neutron qos-policy-create bwlimiter
10. neutron qos-bandwidth-limit-rule-create bwlimiter --max-kbps 13000
11. Find Ubuntu-1 port
12. Update this port with qos-policy bwlimiter
13. Start iperf server on Ubuntu-2
14. Start iperf client on Ubuntu-1
15. Look at the traffic on Ubuntu-1. It is eq qos-policy bwlimiter
16. nova delete Ubuntu-1
17. nova delete Ubuntu-2
18. neutron router-interface-delete router01 subnet01
19. neutron router-interface-delete router01 admin_floating_net__subnet
20. neutron net-delete net01
21. repeat steps 1-8
22. Find Ubuntu-1 port
24. Update this port with qos-policy bwlimiter
25. Start iperf server on Ubuntu-2
26. Start iperf client on Ubuntu-1
27. Look at the traffic on Ubuntu-1.
28. bandwidth-limit-rule ID=`neutron qos-bandwidth-limit-rule-list bwlimiter | grep 13000 | awk '{print $2}'`
29. Update bandwidth-limit-rule. neutron qos-bandwidth-limit-rule-update $ID bwlimiter --max-kbps 20000
30. Look at the traffic on Ubuntu-1. It is not changed and equal 13000 instead of 20000

Expected results:
Traffic restriction must be equal bandwidth-limit-rule (20000 kbps)

Actual result:
Traffic restriction equal bandwidth-limit-rule that was created befor deleting router,net,VMs (13000 kbps)

Additional information:

There is some logs from /var/log/neutron/neutron-openvswitch-agent.log on node-2 after updating bandwidth-limit-rule

http://paste.openstack.org/show/496886/

Description of the environment:

fuel_build_id | 308 |

fuel_build_number | 308 |

fuel_release | 9.0 |

fuel_openstack_version | mitaka-9.0 |

Diagnostic snapshot - http://mos-scale-share.mirantis.com/fuel-snapshot-2016-05-11_19-00-11.tar.xz

Sergii (sgudz)
description: updated
Revision history for this message
Mikhail Chernik (mchernik) wrote :

Probably, the same bug in upstream: https://bugs.launchpad.net/neutron/+bug/1515533

Changed in mos:
assignee: nobody → MOS Neutron (mos-neutron)
Changed in mos:
status: New → Confirmed
importance: Undecided → High
milestone: none → 9.0
tags: added: area-neutron
Revision history for this message
Ilya Chukhnakov (ichukhnakov) wrote :

mitaka/9.0 backport would also require https://review.openstack.org/#/c/300679

Revision history for this message
Ilya Chukhnakov (ichukhnakov) wrote :
Revision history for this message
Ilya Chukhnakov (ichukhnakov) wrote :
Revision history for this message
Alexander Ignatov (aignatov) wrote :

Set to In progress until this patch https://review.fuel-infra.org/#/c/21353/ is merged to MOS stable/mitaka

Revision history for this message
Fuel Devops McRobotson (fuel-devops-robot) wrote : Fix merged to openstack/neutron (9.0/mitaka)

Reviewed: https://review.fuel-infra.org/21353
Submitter: Pkgs Jenkins <email address hidden>
Branch: 9.0/mitaka

Commit: bbb7be45d78dd4c1f17fe4cb1d96f42bd073018b
Author: Jenkins <email address hidden>
Date: Sun May 29 15:43:00 2016

Merge the tip of origin/stable/mitaka into origin/9.0/mitaka

18bb187 DVR: Ensure fpr and rfp devices are configured correctly
b6d9923 DVR: Use existing IPDevice to add address on FIP VETH
7d2fc6d Call ext_manager.delete_port on port removal
a5e3f00 Improve handle port_update and port_delete events in ovs qos agent
5d57c7c DVR: Use IPDevice class consistently
22893d1 Fix Windows IPDevice.device_has_ip racefulness
a07c68a Avoid L3 agent termination without server
1e8863a Fix for 'ofport' query retries during neutron agent start

Closes-Bug: #1580985
Change-Id: I3715de54f38b2185e23c5d126a8c44dc7982ca88

tags: added: on-verification
Revision history for this message
Kristina Berezovskaia (kkuznetsova) wrote :

Verify on
cat /etc/fuel_build_id:
 449
cat /etc/fuel_build_number:
 449
cat /etc/fuel_release:
 9.0
cat /etc/fuel_openstack_version:
 mitaka-9.0
rpm -qa | egrep 'fuel|astute|network-checker|nailgun|packetary|shotgun':
 fuel-release-9.0.0-1.mos6347.noarch
 fuel-provisioning-scripts-9.0.0-1.mos8723.noarch
 python-packetary-9.0.0-1.mos140.noarch
 fuel-bootstrap-cli-9.0.0-1.mos285.noarch
 fuel-migrate-9.0.0-1.mos8435.noarch
 shotgun-9.0.0-1.mos90.noarch
 fuel-notify-9.0.0-1.mos8435.noarch
 python-fuelclient-9.0.0-1.mos323.noarch
 fuel-9.0.0-1.mos6347.noarch
 fuel-setup-9.0.0-1.mos6347.noarch
 fuel-misc-9.0.0-1.mos8435.noarch
 fuel-library9.0-9.0.0-1.mos8435.noarch
 network-checker-9.0.0-1.mos74.x86_64
 fuel-agent-9.0.0-1.mos285.noarch
 fuel-ui-9.0.0-1.mos2715.noarch
 fuel-ostf-9.0.0-1.mos935.noarch
 fuelmenu-9.0.0-1.mos272.noarch
 fuel-nailgun-9.0.0-1.mos8723.noarch
 rubygem-astute-9.0.0-1.mos748.noarch
 fuel-mirror-9.0.0-1.mos140.noarch
 fuel-openstack-metadata-9.0.0-1.mos8723.noarch
 nailgun-mcagents-9.0.0-1.mos748.noarch
 fuel-utils-9.0.0-1.mos8435.noarch

Repeat steps, traffic restriction must is nearly equal new bandwidth-limit-rule restriction

tags: removed: on-verification
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.