tc doesn't support vif quota values bigger than 32 bits unsigned

[David Hill]

tc doesn't support vif quota values bigger than 32 bits unsigned. libvirt appends "kb" to the vif quota sizes which will definitely , in some cases, go above the 4294967295 if the customer is specifying a somehwat reasonable value such as this:

quota:vif_inbound_average=10000
quota:vif_inbound_burst=15000000
quota:vif_inbound_peak=50000
quota:vif_outbound_average=10000
quota:vif_outbound_burst=15000000
quota:vif_outbound_peak=50000

In this case, the burst size is 15000000 * 1024 = 15360000000 which is above 4294967295. The following value makes libvirt fail with this undecipherable error message:

[root@undercloud-0-rhosp16 ~]# tc class add dev eth0 parent 1: classid 1:1 htb rate 10000 ceil 50000 burst 15000000kb quantum 853
Illegal "buffer"
Usage: ... qdisc add ... htb [default N] [r2q N]
.

We have about 3 ways to fix this:
1) fix "tc" to not fail if a value is invalid
2) fix libvirtd to remove the "kb"
3) fix nova_compute to fail with an error message or lower the value.

[sean mooney (sean-k-mooney)]

technically these flavor extra specs are ment to be hypervisor independent and we in generall should not enforce limits based on any one implementaiton such as tc.

with that said uint32_max is proably an ok limit to enforce in the general case.

the correct way to enforece this in nova is via the flavor extra spec json schema validations

in addtion to that a second check should be implemented when assigning to nova config object in the libvirt driver that model the xml elements.

we should fail the boot of the server in this case setting it to error and stating that the flavor extra specs exceed the maxium allowable value.

we should also likely update the documentaiton for the extra specs to not that for the libvirt driver the values should be specifed in KB not bytes

[sean mooney (sean-k-mooney)]

https://github.com/openstack/nova/blob/3a14c1a4277a9f44b67e080138b28b680e5e6824/nova/api/validation/extra_specs/quota.py#L169-L187

this is where the validation code currently is

by the way as the comment suggest we dont really advice that anyone use the vif quotas anymore and are considering removing them eventually but just have not seen it as a priority.

as an aside this does not work with ovn, hardware offloade ovs, ovs-dpdk or ml2/ovs with ovs firewall.

when using kernel ovs if the tap device is added ot ovs the tc rules do not work.
for vhost-user which is entirely impemented in userspce tc rules obvioulsy do not work
for hard ware offloaded ovs libvirt based qos has never been supported and i dont think it can be impleted this way either.

so while this technically can be used with ml2/ovs with iptable or linux bridge in generall the quta functional does not work with most network backend which is why we want to eventually remvoe this in foavor of neutron qos which does work in many of those cases.

that is why i have marked this as which list as really its just a documentaiton issue where we have not specified the allowed range. we can add validation as i have suggested but in general this is more operator error then anythign else for configuring vaules outside the rage.
we dont however expect operators to look at the internal of nova to discover that so we should document the preconditions and detct invalid values which is why i have triaged this as whishlist instead of markign it as invalid