Public bug reported: ### Bug in documentation ### https://docs.openstack.org/neutron/queens/admin/config-qos.html
1) Commands’ order “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:” After the above sentence we have “openstack port show a7f25e73-4288-4a16-93b9-b71e6fd00862” command, why? This “SHOW” command shows port’s details only, but next command “openstack floating ip set --port a7f25e73-4288-4a16-93b9-b71e6fd00862 0eeb1f8a-de96-4cd9-a0f6-3f535c409558” does the associating, so it’s seems to me that commands’ order must be changed. Also by doing that we can point out user that “qos_policy_id” value in “Show” output has valid ID, means that associating is done as expected. 2) Unknown ID “0eeb1f8a-de96-4cd9-a0f6-3f535c409558” As potential user, I would expect to see one of the the IDs received in “openstack floating ip list” command’s output as parameter for “openstack floating ip set ...”, but actually we have “0eeb1f8a-de96-4cd9-a0f6-3f535c409558” and we don’t have such ID in our Floating IP list. ** Affects: neutron Importance: Undecided Status: New ** Tags: doc ** Description changed: ### Bug in documentation ### + https://docs.openstack.org/neutron/queens/admin/config-qos.html 1) Commands’ order “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:” - After the above sentence we have “openstack port show a7f25e73-4288-4a16-93b9-b71e6fd00862” command, why? + After the above sentence we have “openstack port show a7f25e73-4288-4a16-93b9-b71e6fd00862” command, why? This “SHOW” command shows port’s details only, but next command “openstack floating ip set --port a7f25e73-4288-4a16-93b9-b71e6fd00862 0eeb1f8a-de96-4cd9-a0f6-3f535c409558” does the associating, so it’s seems to me that commands’ order must be changed. Also by doing that we can point out user that “qos_policy_id” value in “Show” output has valid ID, means that associating is done as expected. 2) Unknown ID “0eeb1f8a-de96-4cd9-a0f6-3f535c409558” As potential user, I would expect to see one of the the IDs received in “openstack floating ip list” command’s output as parameter for “openstack floating ip set ...”, but actually we have “0eeb1f8a-de96-4cd9-a0f6-3f535c409558” and we don’t have such ID in our Floating IP list. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1778740 Title: Quality of Service (QoS) in Neutron - associating QoS policy to Floating IP Status in neutron: New Bug description: ### Bug in documentation ### https://docs.openstack.org/neutron/queens/admin/config-qos.html 1) Commands’ order “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:” After the above sentence we have “openstack port show a7f25e73-4288-4a16-93b9-b71e6fd00862” command, why? This “SHOW” command shows port’s details only, but next command “openstack floating ip set --port a7f25e73-4288-4a16-93b9-b71e6fd00862 0eeb1f8a-de96-4cd9-a0f6-3f535c409558” does the associating, so it’s seems to me that commands’ order must be changed. Also by doing that we can point out user that “qos_policy_id” value in “Show” output has valid ID, means that associating is done as expected. 2) Unknown ID “0eeb1f8a-de96-4cd9-a0f6-3f535c409558” As potential user, I would expect to see one of the the IDs received in “openstack floating ip list” command’s output as parameter for “openstack floating ip set ...”, but actually we have “0eeb1f8a-de96-4cd9-a0f6-3f535c409558” and we don’t have such ID in our Floating IP list. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1778740/+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