Flavors in Administrator Guide - confusing description for rxtx factor

Bug #1688054 reported by Matt Riedemann on 2017-05-03
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openstack-manuals
Medium
Unassigned

Bug Description

- [x] This doc is inaccurate in this way: ______

The RXTX Factor description currently states:

"Optional property allows created servers to have a different bandwidth cap than that defined in the network they are attached to. This factor is multiplied by the rxtx_base property of the network. Default value is 1.0. That is, the same as attached network. This parameter is only available for Xen or NSX based systems."

The compute API reference has a better and more accurate description:

https://developer.openstack.org/api-ref/compute/?expanded=create-flavor-detail#create-flavor

"The receive / transmit factor (as a float) that will be set on ports if the network backend supports the QOS extension. Otherwise it will be ignored. It defaults to 1.0."

The admin guide description is really talking about nova-network and the xen virt driver, which is not untrue, but is a bit confusing (I don't know where the NSX part comes from).

But the way this is used with neutron in nova is on the port if the QOS extension is enabled. Nova will likely deprecate this field in the flavor resource since nova-network is deprecated and if you're doing QOS on ports you should be doing that via the networking service, not the compute service flavors.

-----------------------------------
Release: 15.0.0 on 2017-05-03 11:19
SHA: 991820bc90e3f08a7ddfd1a649bc78a12a9406ab
Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/admin-guide/source/compute-flavors.rst
URL: https://docs.openstack.org/admin-guide/compute-flavors.html

Matt Riedemann (mriedem) on 2017-05-03
tags: added: compute flavors
Anne Gentle (annegentle) on 2017-05-13
Changed in openstack-manuals:
status: New → Confirmed
importance: Undecided → Medium
tags: added: low-hanging-fruit
Anne Gentle (annegentle) wrote :

I think NSX stands for VMWare NSX, which is their networking virtualization platform. I think adding VMWare NSX helps provide the additional context an admin would need in this doc.

Matt Riedemann (mriedem) wrote :

Anne, the issue I have with calling out NSX is in "This parameter is only available for Xen or NSX based systems." - there is nothing specific about NSX or the vmware driver for the rxtx_factor in nova, so it's just kind of weird. If you have that flavor set it's global to all compute driver backends when using neutron in nova. That's why I think the more generic description from the compute API reference is better.

Anne Gentle (annegentle) wrote :

Or, perhaps NSX was a typo from before? Anyway, here's how I'd re-write this:

"Optional property that stands for receive / transmit (rxtx) factor. Can only be set on ports if the network backend supports the Quality of Service (QOS) extension, which includes Xen with nova-network. The rxtx factor is multiplied by the rxtx_base property of the network. Default value is 1.0, meaning, the receive / transmit value has the same value as attached network."

Anne Gentle (annegentle) on 2017-05-15
Changed in openstack-manuals:
status: Confirmed → Triaged
Changed in openstack-manuals:
assignee: nobody → omkar_telee (omkar-telee)
omkar_telee (omkar-telee) wrote :

I agree with Anne, making the change.

omkar_telee (omkar-telee) wrote :

@Matt, I have found few more references here, I think we should recheck this functionality
https://docs.openstack.org/cli-reference/glance-property-keys.html
https://docs.openstack.org/admin-guide/cli-manage-flavors.html

can you go through following links and update us little more,
https://wiki.openstack.org/wiki/NetworkBandwidthEntitlement
https://serverfault.com/questions/656582/what-does-rxtx-factor-mean-what-is-it-and-how-does-it-affect-my-server

I am not sure, this factor really works with KVM or not.

Ben Silverman (tersian) on 2017-05-31
Changed in openstack-manuals:
status: Triaged → Confirmed
Changed in openstack-manuals:
assignee: omkar_telee (omkar-telee) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers