On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote:Because layered products (not just OpenShift) do not want to be coupled to the RHEL release schedule to update their profiles. They want to own their profiles and rely on the tuned daemon to be there.I see two aspects to this discussion:1) Generic tradeoffs with host configuration2) The specific discussion about tuned profilesFollowing 2) if I run:$ cd ~/src/github/openshift/origin$ git describe --tags --alwaysv1.3.0-rc1-14-ge9081ae$ git log --follow contrib/tuned/origin-node-
host/tuned.confThere are a grand total of *two* commits that aren't merecode reorganization:commit d959d25a405bb28568a17f8bf1b79e 7d427ae0dcAuthor: Jeremy Eder <jeder redhat com>AuthorDate: Tue Mar 29 10:40:03 2016 -0400Commit: Jeremy Eder <jeder redhat com>CommitDate: Tue Mar 29 10:40:03 2016 -0400bump inotify watchescommit c11cb47c07e24bfeec22a7cf94b0d6 d693a00883Author: Scott Dodson <sdodson redhat com>AuthorDate: Thu Feb 12 13:06:57 2015 -0500Commit: Scott Dodson <sdodson redhat com>CommitDate: Wed Mar 11 16:41:08 2015 -0400Provide both a host and guest profileThat level of change seems quite sufficient for the slowerRHEL cadence, no?
Particularly when one considers that something like theinotify watch bump could easily be part of a "tuned updates"in the installer that would live there until the base tunedprofile updates.Right?
Before we go the layered RPM route I just want to make sure you're onboard with it, as I was not aware of any existing in-product users of that feature. Are there any? If we're the first that's not an issue, just want to make sure we get it right.In this particular case of tuned, I'd argue that Atomic Host should come out of the box with these profiles,and that any async updates could be done via the openshift-ansible installer.