- [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
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.