@LIU Yulong

I think that you missed the main point somehow :(

The problem occurs when you trying to associate "Floating IP" with QoS enabled 
to the neutron port, the bug is in step 4! 
In another words "binding Floating IP with QoS enabled" to neutron port fails.
And yes you are right QoS is added to Floating IP without problem and proper ID 
is shown in qos_policy_id instead of default "None" when you run "openstack 
floating ip show ID/IP" command.

### Note: ###
Having Floating IP with QoS enabled,in system, without being associated to 
Neutron port doesn't make sense, you have to bind this IP to port in order to 
activate QoS physically, just as it explained in documentation. 

So there are to mandatory steps to do the above:
1) Add QoS to Floating IP --> PASS
2) Associate/bind previously created Floating IP to the Neutron Port --> FAILS




 




** Changed in: neutron
       Status: Invalid => In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1781892

Title:
  QoS – Neutron port is not effected after association “Floating IP”
  with “QoS policy” enabled

Status in neutron:
  In Progress

Bug description:
  
  ### Feature description ###
  According QoS documentation 
https://docs.openstack.org/neutron/queens/admin/config-qos.html it’s possible 
to add QoS policy to the Floating IP and then to attach this Floating IP to the 
Neutron port in order to get QoS activated.
  From documentation:
  The created policy can be associated with an existing floating IP. In order 
to do this, user extracts the floating IP id to be associated to the already 
created policy. In the next example, we will assign the bw-limiter policy to 
the floating IP address 172.16.100.18.
  The QoS bandwidth limit rules attached to a floating IP will become active 
when you associate the latter with a port. For example, to associate the 
previously created floating IP 172.16.100.12 to the instance port with fixed IP 
192.168.222.5:

  ### Scenario ###
  Connect to your undercloud host, source to overcloudrc and execute the 
folowing commands:
  1 - Create policy - "openstack network qos policy create bw-limiter" 
  2 - Create rule - "openstack network qos rule create --type bandwidth-limit 
--max-kbps 3000 --max-burst-kbits 2400 --egress bw-limiter"
  3 - Enable QoS to my Floating IP - "openstack floating ip set --qos-policy 
bw-limiter 10.0.0.220 "
  4 - Associating FloatingIp to Port - "openstack floating ip set --port 
vm1_port 10.0.0.220"

  ### Expected ###
  Once QoS is associated to the port it should be effected in “openstack port 
show vm1_port” its output should contain valid ID in “qos_policy_id” parameter, 
but actually it’s None.
  I’ve tried to run the manual test (checking actual BW that supposed to be 
limited) in spite of the fact configuration wasn’t effected and the result is 
that no BW limit was detected, means no QoS.
    

  ### Note ###
  There are no errors or warnings in CLI while configuration, the only thing 
that I see in server.log while executing step #4 is:

  2018-06-26 14:42:07.980 27 DEBUG neutron.wsgi [-] (27) accepted 
('172.17.1.10', 52720) server /usr/lib/python2.7/site-
  2018-06-26 14:42:07.982 27 INFO neutron.wsgi [-] 172.17.1.10 "OPTIONS / 
HTTP/1.0" status: 200  len: 248 time: 0.0014350
  2018-06-26 14:42:08.624 29 DEBUG neutron.wsgi [-] (29) accepted 
('172.17.1.10', 52748) server /usr/lib/python2.7/site-
  2018-06-26 14:42:08.626 29 INFO neutron.wsgi [-] 172.17.1.10 "GET / HTTP/1.1" 
status: 200  len: 229 time: 0.0011430
  2018-06-26 14:42:09.123 31 DEBUG neutron_lib.callbacks.manager 
[req-916b4dfe-8370-43df-a58b-
  2018-06-26 14:42:09.984 26 DEBUG neutron.wsgi [-] (26) accepted 
('172.17.1.10', 52768) server /usr/lib/python2.7/site-
  2018-06-26 14:42:09.986 26 INFO neutron.wsgi [-] 172.17.1.10 "OPTIONS / 
HTTP/1.0" status: 200  len: 248 time: 0.0012841
  2018-06-26 14:42:11.942 29 DEBUG neutron.wsgi [-] (29) accepted 
('172.17.1.10', 52810) server /usr/lib/python2.7/site-
  2018-06-26 14:42:11.986 26 DEBUG neutron.wsgi [-] (26) accepted 
('172.17.1.10', 52816) server /usr/lib/python2.7/site-
  2018-06-26 14:42:11.988 26 INFO neutron.wsgi [-] 172.17.1.10 "OPTIONS / 
HTTP/1.0" status: 200  len: 248 time: 0.0009670
  2018-06-26 14:42:12.150 34 DEBUG neutron_lib.callbacks.manager 
[req-9ef05eda-b272-449b-9cdc-
  2018-06-26 14:42:12.179 29 INFO neutron.api.v2.resource 
[req-78f37d24-bcee-49b6-8102-
  2018-06-26 14:42:12.180 29 INFO neutron.wsgi [req-78f37d24-bcee-49b6-8102-GET 
/v2.0/floatingips/10.0.0.220HTTP/1.1" status: 404  len: 300 time: 0.2373581
  2018-06-26 14:42:12.216 29 INFO neutron.wsgi [req-da7e5822-e39a-44b0-ba27-
  2018-06-26 14:42:12.256 29 INFO neutron.pecan_wsgi.hooks.
  2018-06-26 14:42:12.257 29 INFO neutron.wsgi [req-e2ac800a-6ed3-4f4b-abcc-GET 
/v2.0/ports/vm1_port HTTP/1.1" status: 404  len: 286 time: 0.0336130
  2018-06-26 14:42:12.317 29 INFO neutron.wsgi [req-ee029893-8b36-4b6f-82ba-
  2018-06-26 14:42:13.988 28 DEBUG neutron.wsgi [-] (28) accepted 
('172.17.1.10', 52854) server /usr/lib/python2.7/site-
  2018-06-26 14:42:13.990 28 INFO neutron.wsgi [-] 172.17.1.10 "OPTIONS / 
HTTP/1.0" status: 200  len: 248 time: 0.0009780

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1781892/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to