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

[Arkady Shtempler]

### 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

[LIU Yulong (dragon889)]

``3 - Enable QoS to my Floating IP - "openstack floating ip set --qos-policy bw-limiter 10.0.0.220 "``
After this action, you can show the FLOATING IP qos policy by:
openstack floating ip show <fip_id>
something like this:
openstack floating ip show 172.16.100.103
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| created_at | 2018-06-27T05:03:30Z |
| description | |
| fixed_ip_address | 192.168.111.5 |
| floating_ip_address | 172.16.100.103 |
| floating_network_id | 0230d7b0-37cc-402d-a659-de3737618be5 |
| id | 796484e7-095f-45ac-8fa0-5c2ad4912b6f |
| name | 172.16.100.103 |
| port_id | f176f887-d6b8-4bdb-ade0-01784de4174f |
| project_id | a890d8d8264640ba9bae20d03e4071fd |
| qos_policy_id | d5d3484d-6b75-4144-9350-d871f593ea7b |
| revision_number | 9 |
| router_id | 5d7faa50-0558-4db2-ae2d-dce894fc350a |
| status | ACTIVE |
| subnet_id | None |
| updated_at | 2018-07-11T07:47:25Z |
+---------------------+--------------------------------------+

The qos policy is binding to the `floating IP` itself, not the `port` which floating IP binded to.

[Arkady Shtempler (ashtempl)]

@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

[LIU Yulong (dragon889)]

Again, the qos policy is binding to the `floating IP` itself, not the `port` which floating IP binded to.
Floating IP QoS is only used for the L3 IP. Port qos is L2 perspective.
And neutron will not pass the qos_policy_id of `floating IP` to the binded `port`.
Let me paste you in detail:
http://paste.openstack.org/show/726185/

So why here FAILS? Seems does not make sense.
`2) Associate/bind previously created Floating IP to the Neutron Port --> FAILS`

[LIU Yulong (dragon889)]

According to the bug title
"QoS – Neutron port is not effected after association “Floating IP” with “QoS policy” enabled"
I think you misunderstaning the L2 qos and L3 IP QoS.
If you want that floating IP binded port have qos_policy, you need to bind qos policy to it manually.

[Arkady Shtempler (ashtempl)]

Please pass over latest QoS documentation and two sentences from there, just as mentioned in ### Bug Description ### section

# Link to QoS documentation --> https://docs.openstack.org/neutron/queens/admin/config-qos.html

# Document sentence 1 --> 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.

# Document sentence 2 --> 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:

Actually my the test scenario is copy/paste from documentation, as simple as is.
Manually executing examples' CLI commands int the same order as provided in documentation.

So why do you think that i'm misunderstanding something?
BTW this is exactly what will be done by potential administrator/user, once he is interesting to activate QoS using Floating IP option.

Do you think that provided documentation is incorrect?

[LIU Yulong (dragon889)]

Documentation is right.

Your bug description is incorrect:
"""
### 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.
"""

Again and again:
1)
Your step 3 will not effect the port `vm1_port` in your step 4 which means "the qos policy is binding to the `floating IP` itself, not the `port` which floating IP binded to."
2)
If you want that vm1_port have qos_policy, you need to bind qos policy to it manually.
3)
Try to find out the difference between L2 qos and L3 IP QoS.

[Arkady Shtempler (ashtempl)]

OK, I got it now, thanks!
:)
Due to the fact that in both "show" command's outputs: "port" and "floating IP" we have the same value "qos_policy_id" it confused me a bit, as I though that in both cases we are talking about the same QoS policy, but actually these two IDs are different and we don't have an option (at least in show output) to distinguish between them.
I'll change the test scenario accordingly and will take into consideration QoS L2 and QoS L3 on functionality level.
I would expect if so, to change the value name for "Floating IP" to "qos_policy_id_L3" and for Neutron port "qos_policy_id_L2" (just an example) such change (RFC) will effect other areas in QoS , it's clear to me.
Do you think that current implementation and document's description won't confuse administrators?
Am I the only one who didn't get it properly? :(
Don't you think that enhancement/RFC could be relevant?

[OpenStack Infra (hudson-openstack)]

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

[Slawek Kaplonski (slaweq)]

So I think that doing it with 2 separate policies might also confuse users that same policy can't be used for both: ports and floating IPs.
I proposed some additional note to make it more clear. Please check if that would be enough in Your opinion :)
Patch is here: https://review.openstack.org/583967

[Arkady Shtempler (ashtempl)]

I think that adding such a note will be OK.

[OpenStack Infra (hudson-openstack)]

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

commit 7a92d44bfa6aeb96f61b95a96b4248a80b5d4544
Author: Slawek Kaplonski <email address hidden>
Date: Thu Jul 19 16:00:04 2018 +0200

    [Docs] Add note about Floating IP QoS

    As it might be confusing for users that ID of QoS policy
    attached to FIP will be also visible in port's attributes
    after associate FIP with port this patch adds small note
    about that in QoS documentation.

    This patch clarify also rules from which QoS policy will
    be instelled by L3 agent in case when different QoS polies
    are associated with a port and a floating IP.

    Additionally this commit fixes also one typo found in
    qos configs document.

    Change-Id: I13e49a12be61407fa0f2898bef7deda64a04a1f5
    Closes-Bug: 1781892

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 13.0.0.0rc1 release candidate.