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
