Hello Jorge, or anyone else affected, Accepted neutron into ocata-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.
Please help us by testing this new package. To enable the -proposed repository: sudo add-apt-repository cloud-archive:ocata-proposed sudo apt-get update Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-ocata-needed to verification-ocata-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ocata-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: cloud-archive/ocata Status: Won't Fix => Fix Committed ** Tags removed: verification-ocata-failed ** Tags added: verification-ocata-needed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1841700 Title: instance ingress bandwidth limiting doesn't works in ocata. Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive ocata series: Fix Committed Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Xenial: Invalid Bug description: [Environment] Xenial-Ocata deployment [Description] The instance ingress bandwidth limit implementation was targeted for Ocata [0], but the full implementation ingress/egress was done during the pike [1] cycle. However, isn't reported or explicit that ingress direction isn't supported in ocata, which causes the following exception when --ingress is specified. It would be desirable for this feature to be available on Ocata for being able to set ingress/egress bandwidth limits on the ports. [Testing] Without these patches, trying to set a ingress bandwidth-limit rule the following exception will be raised. $ openstack network qos rule create --type bandwidth-limit --max-kbps 300 --max-burst-kbits 300 --ingress bw-limiter Failed to create Network QoS rule: BadRequestException: 400: Client Error for url: https://openstack:9696/v2.0/qos/policies/xxxx/bandwidth_limit_rules, Unrecognized attribute(s) 'direction' A single policy set (without the --ingress parameter) as supported in Ocata will just create a limiter on the egress side. 1) Check the policy list $ openstack network qos policy list +--------------------------------------+------------+--------+---------+----------------------------------+ | ID | Name | Shared | Default | Project | +--------------------------------------+------------+--------+---------+----------------------------------+ | 2c9c85e2-4b65-4146-b7bf-47895379c938 | bw-limiter | False | None | c45b1c0a681d4d9788f911e29166056d | +--------------------------------------+------------+--------+---------+----------------------------------+ 2) Check that the qoes rule is set to 300 kbps. $ openstack network qos rule list 2c9c85e2-4b65-4146-b7bf-47895379c938 | 01eb228d-5803-4095-9e8e-f13d4312b2ef | 2c9c85e2-4b65-4146-b7bf- 47895379c938 | bandwidth_limit | 300 | 300 | | | | 3) Set the Qos policy on any port. $ openstack port set 9a74b3c8-9ed8-4670-ad1f-932febfcf059 --qos-policy 2c9c85e2-4b65-4146-b7bf-47895379c938 $ openstack port show 9a74b3c8-9ed8-4670-ad1f-932febfcf059 | grep qos | qos_policy_id | 2c9c85e2-4b65-4146-b7bf-47895379c938 | 4) Check that the egress traffic rules have been applied # iperf3 -c 192.168.21.9 -t 10 Connecting to host 192.168.21.9, port 5201 [ 4] local 192.168.21.3 port 34528 connected to 192.168.21.9 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 121 KBytes 988 Kbits/sec 23 2.44 KBytes [ 4] 7.00-8.00 sec 40.2 KBytes 330 Kbits/sec 14 3.66 KBytes [ 4] 8.00-9.00 sec 36.6 KBytes 299 Kbits/sec 15 2.44 KBytes [ 4] 9.00-10.00 sec 39.0 KBytes 320 Kbits/sec 18 3.66 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 435 KBytes 356 Kbits/sec 159 sender [ 4] 0.00-10.00 sec 384 KBytes 314 Kbits/sec receiver iperf Done. 5) Check that no ingress traffic limit has been applied. # iperf3 -c 192.168.21.9 -R -t 10 Connecting to host 192.168.21.9, port 5201 Reverse mode, remote host 192.168.21.9 is sending [ 4] local 192.168.21.3 port 34524 connected to 192.168.21.9 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 38.1 MBytes 319 Mbits/sec [ 4] 8.00-9.00 sec 74.6 MBytes 626 Mbits/sec [ 4] 9.00-10.00 sec 73.2 MBytes 614 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.07 GBytes 918 Mbits/sec 1045 sender [ 4] 0.00-10.00 sec 1.07 GBytes 916 Mbits/sec receiver ---> 6) With the patches applied from the PPA or proposed, run the migration steps on the neutron-api node, repeat the previous steps, but make sure to specify the traffic direction with --ingress as follows: $ openstack network qos rule create --type bandwidth-limit --max-kbps 300 --ingress testing-policy +----------------+--------------------------------------+ | Field | Value | +----------------+--------------------------------------+ | direction | ingress | | id | 6d01cefa-0042-40cd-ae74-bcb723ca7ca4 | | max_burst_kbps | 0 | | max_kbps | 300 | | name | None | | project_id | | +----------------+--------------------------------------+ 7) Set the policy into any server port. $ openstack port set 50b8f714-3ee4-4260-8359-820420471bdb --qos-policy fac2be5e-64e0-4308-b477-0f8c0096c0b8 8) Check that the policy has been applied $ openstack port show 50b8f714-3ee4-4260-8359-820420471bdb | grep qos | qos_policy_id | fac2be5e-64e0-4308-b477-0f8c0096c0b8 | 9) Check that the rules have the "Direction field" $ openstack network qos rule list fac2be5e-64e0-4308-b477-0f8c0096c0b8 +--------------------------------------+--------------------------------------+-----------------+----------+-----------------+----------+-----------+-----------+ | ID | QoS Policy ID | Type | Max Kbps | Max Burst Kbits | Min Kbps | DSCP mark | Direction | +--------------------------------------+--------------------------------------+-----------------+----------+-----------------+----------+-----------+-----------+ | 6d01cefa-0042-40cd-ae74-bcb723ca7ca4 | fac2be5e-64e0-4308-b477-0f8c0096c0b8 | bandwidth_limit | 300 | 0 | | | ingress | +--------------------------------------+--------------------------------------+-----------------+----------+-----------------+----------+-----------+-----------+ 10) Validate that the hypervisor has a ovs queue and qos setup set, max-rate should be set to 300000. $ sudo ovs-vsctl list qos _uuid : 2862acaa-a79f-4a62-b387-f89bca4a6965 external_ids : {id="tap75d95386-01"} other_config : {} queues : {0=a15774f7-ae31-40e7-9c0f-937d68a7dc0c} type : linux-htb root@juju-cd6736-1841700-8:/home/ubuntu# sudo ovs-vsctl list queue _uuid : a15774f7-ae31-40e7-9c0f-937d68a7dc0c dscp : [] external_ids : {id="tap75d95386-01", queue_type="0"} other_config : {burst="0", max-rate="300000"} [0] https://blueprints.launchpad.net/neutron/+spec/instance-ingress-bw-limit [1] https://bugs.launchpad.net/neutron/+bug/1560961 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1841700/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp