QoS - “port” parameter is required in CLI in order to set/unset QoS policy to floating IP

[Arkady Shtempler]

### User Workflow (Documentation) ###
According documentation https://docs.openstack.org/neutron/queens/admin/config-qos.html in order to:

1) Set QoS to Floating IP:
openstack floating ip set --qos-policy bw-limiter d0ed7491-3eb7-4c4f-a0f0-df04f10a067c

2) Remove Floating IP (option 1):
openstack floating ip set --no-qos-policy d0ed7491-3eb7-4c4f-a0f0-df04f10a067c

3) Remove Floating IP (option 2)
openstack floating ip unset --qos-policy d0ed7491-3eb7-4c4f-a0f0-df04f10a067c

### Testing Result ###

1) Set QoS to floating IP
# Scenario #
openstack floating ip set --no-qos-policy b2895ad6-0e17-4be9-bf03-c11010c81584

# Actual Result #
Fails with:
(openstack) floating ip set --no-qos-policy b2895ad6-0e17-4be9-bf03-c11010c81584
usage: floating ip set [-h] --port <port> [--fixed-ip-address <ip-address>]
                       [--qos-policy <qos-policy> | --no-qos-policy]
                       <floating-ip>
floating ip set: error: argument --port is required

There is no match between “set command” in documentation and implemented code.
Once “port” parameter is provided, QoS is set as expected.
“Set command” provided in documentation absolutely OK (“floating-ip” should be a single mandatory parameter), so the problem here is our implementation.
I think that we have to check the “Port” value in our code, basing on provided by user “Floating-IP” and then to use it. So this will be kind of workaround and will be transparent to user.

2) Unset QoS from Floating IP with “set –no-qos-policy” option
# Scenario #
openstack floating ip set --no-qos-policy b2895ad6-0e17-4be9-bf03-c11010c81584

# Actual Result #
Fails with:
(openstack) floating ip set --no-qos-policy b2895ad6-0e17-4be9-bf03-c11010c81584
usage: floating ip set [-h] --port <port> [--fixed-ip-address <ip-address>]
                       [--qos-policy <qos-policy> | --no-qos-policy]
                       <floating-ip>
floating ip set: error: argument --port is required

Similar to previous “Set QoS”, again no match between the command provided in documentation and our current implementation.
And again, documentation command is OK, the problem is in our implementation. My suggestion is the same workaround, means getting “Port” from code, basing on provided “Floating IP”

3) Unset QoS from Floating IP with “unset” option
# Scenario #
openstack floating ip unset --qos-policy b2895ad6-0e17-4be9-bf03-c11010c81584

# Actual Result #
Works as expected and no “port” value is needed, maybe this info will help the developers to understand why #1 and #2 scenarios behaves diferently.

[Lajos Katona (lajos-katona)]

I tried to reproduce on fresh master, without success, see my commands please:
openstack network qos policy create p1
openstack network qos rule create p1 --type bandwidth-limit --max-kbps 1000
openstack floating ip create public
openstack floating ip set --qos-policy p1 bd8de6f8-07b0-48e6-9d8e-5e3a0f88a4e4
openstack floating ip show bd8de6f8-07b0-48e6-9d8e-5e3a0f88a4e4
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| created_at | 2018-07-26T15:11:44Z |
| description | |
| dns_domain | None |
| dns_name | None |
| fixed_ip_address | None |
| floating_ip_address | 172.24.4.6 |
| floating_network_id | e0652260-3d99-446c-af4a-4cb7daaba36d |
| id | bd8de6f8-07b0-48e6-9d8e-5e3a0f88a4e4 |
| name | 172.24.4.6 |
| port_details | None |
| port_id | None |
| project_id | 91c8b75eac0d45d29106e6726981f18b |
| qos_policy_id | 82d52bf7-81ac-45d9-9666-c5dd43cac942 |
| revision_number | 10 |
| router_id | None |
| status | DOWN |
| subnet_id | None |
| tags | [] |
| updated_at | 2018-07-26T15:22:03Z |
+---------------------+--------------------------------------+

openstack floating ip set --no-qos-policy bd8de6f8-07b0-48e6-9d8e-5e3a0f88a4e4
openstack floating ip show bd8de6f8-07b0-48e6-9d8e-5e3a0f88a4e4
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| created_at | 2018-07-26T15:11:44Z |
| description | |
| dns_domain | None |
| dns_name | None |
| fixed_ip_address | None |
| floating_ip_address | 172.24.4.6 |
| floating_network_id | e0652260-3d99-446c-af4a-4cb7daaba36d |
| id | bd8de6f8-07b0-48e6-9d8e-5e3a0f88a4e4 |
| name | 172.24.4.6 |
| port_details | None |
| port_id | None |
| project_id | 91c8b75eac0d45d29106e6726981f18b |
| qos_policy_id | None |
| revision_number | 12 |
| router_id | None |
| status | DOWN |
| subnet_id | None ...

[Lajos Katona (lajos-katona)]

Could you please confirm that you used the latest version of neutron, neutron-lib and osc?

[Arkady Shtempler (ashtempl)]

As you can see in bug description provided documentation link there is for "queens", so I was using OSP13 setup for testing and not "fresh master".
*** Next time I'll include OSP version in bug description ***

(openstack) (overcloud) [stack@undercloud-0 ~]$ rhos-release -L
Installed repositories (rhel-7.5):
  13
  ceph-3
  ceph-osd-3
  rhel-7.5

Bug is reproducible on my OSP13 setup using the same commands from your comment

(overcloud) [stack@undercloud-0 ~]$ openstack network qos policy create p1
+-------------+--------------------------------------+
| Field | Value |
+-------------+--------------------------------------+
| description | |
| id | 65acc974-ce7e-4a99-8f27-b517bfe8db70 |
| is_default | False |
| name | p1 |
| project_id | b79784c5e9fe42af8c94a46b13816baf |
| rules | [] |
| shared | False |
+-------------+--------------------------------------+

(overcloud) [stack@undercloud-0 ~]$ openstack network qos rule create p1 --type bandwidth-limit --max-kbps 1000 --max-burst 1000
+----------------+--------------------------------------+
| Field | Value |
+----------------+--------------------------------------+
| direction | egress |
| id | 4e5dde2a-85d1-492b-93c4-77fc8a54a9b5 |
| max_burst_kbps | 1000 |
| max_kbps | 1000 |
| name | None |
| project_id | |
+----------------+--------------------------------------+

(overcloud) [stack@undercloud-0 ~]$ openstack floating ip create public
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| created_at | 2018-08-16T13:48:33Z |
| description | |
| fixed_ip_address | None |
| floating_ip_address | 10.0.0.220 |
| floating_network_id | 6db170f6-163b-4f16-b05a-07011302908e |
| id | 986f931e-a6cf-48e1-b542-8b29db69ca27 |
| name | 10.0.0.220 |
| port_id | None |
| project_id | b79784c5e9fe42af8c94a46b13816baf |
| qos_policy_id | None |
| revision_number | 0 |
| router_id | None |
| status | DOWN |
| subnet_id | None |
| updated_at | 2018-08-16T13:48:33Z |
+---------------------+--------------------------------------+

(overcloud) [stack@undercloud-0 ~]$ openstack floating ip set --qos-policy p1 986f931e-a6cf-48e1-b542-8b29db...

[Lajos Katona (lajos-katona)]

Arkady: thanks, on stable/queens I reproduced the issue

[Lajos Katona (lajos-katona)]

the patch for this was merged in June:
https://review.openstack.org/575057

I backport it to stable/queens

[Arkady Shtempler (ashtempl)]

Lajos: good news if so, we do have a bug :)
Thanks for update!

[Lajos Katona (lajos-katona)]

I pushed the cherry-picked patch:
https://review.openstack.org/594244

[Slawek Kaplonski (slaweq)]

Fix merged to OSC stable/queens. We can close this issue now

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/python-openstackclient 3.14.3 release.