yahoo-eng-team team mailing list archive

[Arkady Shtempler <1778740@xxxxxxxxxxxxxxxxxx>]

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