[Bug 1841700] Re: instance ingress bandwidth limiting doesn't works in ocata.

Jorge Niedbalski 1841700 at bugs.launchpad.net
Mon Sep 23 20:45:41 UTC 2019


Test results will be collected through
https://docs.google.com/spreadsheets/d/1ajozctmyHAKEBlG2Aet-
Zdv7v9uFcRlIRiW5KeOk778/edit#gid=0 , please feel free to add any missing
test case on that document.

** Description changed:

  [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'
  
- It would be desirable for this feature to be available on Ocata for being able to 
- set ingress/egress bandwidth limits on the ports.
+ 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 at 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

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron in Ubuntu.
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:
  Triaged
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 at 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



More information about the Ubuntu-openstack-bugs mailing list