Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1793867

Summary: Remove Stochastic Fairness Queueing for network QoS
Product: [oVirt] vdsm Reporter: Germano Veit Michel <gveitmic>
Component: SuperVDSMAssignee: Bell Levin <blevin>
Status: CLOSED CURRENTRELEASE QA Contact: Michael Burman <mburman>
Severity: low Docs Contact:
Priority: unspecified    
Version: 4.30.38CC: blevin, bugs, dholler, mperina
Target Milestone: ovirt-4.4.0Flags: dholler: ovirt-4.4?
dholler: devel_ack+
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: rhv-4.4.0-28 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-16 10:36:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Germano Veit Michel 2020-01-22 06:41:34 UTC
When doing git bisect on el7 kernels, without setting any specific version on compile, the kernel ends up as version "3.10.0+"

# uname -r
3.10.0+

vdsm-4.30.38-1.el7ev.x86_64 fails to start because of this, when trying to decide between using SFQ or FC_CODEL qdisc:

It's the only daemon that fails to start due to the unusual kernel version and it's a bit annoying when testing.

Jan 22 16:15:13 host2 daemonAdapter: Traceback (most recent call last):
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/share/vdsm/supervdsmd", line 26, in <module>
Jan 22 16:15:13 host2 daemonAdapter: supervdsm_server.main(sys.argv[1:])
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 294, in main
Jan 22 16:15:13 host2 daemonAdapter: module_name))
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
Jan 22 16:15:13 host2 daemonAdapter: __import__(name)
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_api/network.py", line 25, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from vdsm.network.api import (setSafeNetworkConfig, setupNetworks,
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 34, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from vdsm.network import netswitch
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch/__init__.py", line 23, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from . import configurator
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch/configurator.py", line 33, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from vdsm.network import ifacquire
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/ifacquire.py", line 31, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from .configurators import ifcfg
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/configurators/__init__.py", line 32, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from . import qos
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/configurators/qos.py", line 33, in <module>
Jan 22 16:15:13 host2 daemonAdapter: _FAIR_QDISC_KIND = 'fq_codel' if (StrictVersion(os.uname()[2].split('-')[0]) >
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib64/python2.7/distutils/version.py", line 40, in __init__
Jan 22 16:15:13 host2 daemonAdapter: self.parse(vstring)
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib64/python2.7/distutils/version.py", line 107, in parse
Jan 22 16:15:13 host2 daemonAdapter: raise ValueError, "invalid version number '%s'" % vstring
Jan 22 16:15:13 host2 daemonAdapter: ValueError: invalid version number '3.10.0+'

Perhaps specifically check if the kernel has the qdisc compiled is both less strict and more reliable?

# grep FQ_CODEL /boot/config-3.10.0-1062.9.1.el7.x86_64
CONFIG_NET_SCH_FQ_CODEL=m

Comment 1 Germano Veit Michel 2020-01-22 06:41:54 UTC
And feel free to close the BZ if its not trivial to improve it, it's easy to workaround.

Comment 2 Dominik Holler 2020-02-05 19:23:14 UTC
I found no reason to keep the support for sfq. Let's remove sfq support.

Comment 5 Lukas Svaty 2020-04-16 10:36:49 UTC
Closing low severity bugs, based on QE capacity, if you would like to still verify this issue please reopen.