Bug 1461838

Summary: RFE: Add "process" rule for recommend_profile
Product: Red Hat Enterprise Linux 7 Reporter: Jiří Mencák <jmencak>
Component: tunedAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED ERRATA QA Contact: Meng Bo <bmeng>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.4CC: jeder, jskarvad, mifiedle, olysonek, psklenar, salmy, tcerna, xtian, zzhao
Target Milestone: rcKeywords: FutureFeature, Patch, Upstream
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: tuned-2.9.0-0.1.rc1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 16:04:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1465887, 1467576, 1485946    

Description Jiří Mencák 2017-06-15 12:34:11 UTC
Description of problem:
There is currently no way of "recommend"ing a profile based on processes running on the system.  I believe it would be useful if a "tuned" user could specify (in /etc/tuned/recommend.conf) something like

[my-profile-based-on-existing-process-name]
process=<regex>

Multiple process=<regex> key-value pairs within a profile section would serve as a logical AND condition, i.e. the profile would only be selected if all processes were running on the system.

Version-Release number of selected component (if applicable):
tuned-2.8.0-4.el7.noarch

Additional information:
At the moment the motivation for this is selecting a tuned profile for an Openshift router based on the presence of a haproxy process, but I'm sure there might be other use cases.

Comment 2 Jaroslav Škarvada 2017-06-15 14:24:59 UTC
I think it will be beneficial.

Unfortunately the current parser (configobj) doesn't allow multiple keywords (i.e. multiple 'process=regex' lines), but it shouldn't be problem to differentiate it by unique suffix, e.g.:

process=regex1
process1=regex2
process2=regex3

Comment 3 Jaroslav Škarvada 2017-06-15 16:24:01 UTC
Upstream patch adding this functionality:
https://github.com/redhat-performance/tuned/commit/5a2ea01f719c096dd8abdf3050e8b34b9d30ce2b

Comment 5 Jiří Mencák 2017-06-16 07:32:05 UTC
Tested upstream patch in #3, works fine.

Comment 9 Fedora Update System 2017-10-13 14:19:53 UTC
tuned-2.9.0-0.1.rc1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d9c6b990df

Comment 10 Fedora Update System 2017-10-13 22:24:47 UTC
tuned-2.9.0-0.1.rc1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d9c6b990df

Comment 11 Fedora Update System 2017-10-13 23:24:37 UTC
tuned-2.9.0-0.1.rc1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5f0849d207

Comment 12 zhaozhanqi 2017-10-16 07:45:39 UTC
Verified this bug with # tuned -v
tuned 2.9.0

the node can get the correct value

# sysctl -a | grep ipv4.neigh.default.gc_thresh
sysctl: reading key "net.ipv6.conf.all.stable_secret"
net.ipv4.neigh.default.gc_thresh1 = 8192
net.ipv4.neigh.default.gc_thresh2 = 32768
net.ipv4.neigh.default.gc_thresh3 = 65536

Comment 14 Fedora Update System 2017-10-29 21:06:10 UTC
tuned-2.9.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-0e45ce4685

Comment 15 Fedora Update System 2017-10-29 21:12:20 UTC
tuned-2.9.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c30e9bd1ea

Comment 18 errata-xmlrpc 2018-04-10 16:04:16 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0879