On Wed, Oct 12, 2016 at 10:29 AM, Colin Walters <walt...@verbum.org> wrote:

> 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 configuration
> 2) The specific discussion about tuned profiles
> Following 2) if I run:
> $ cd ~/src/github/openshift/origin
> $ git describe --tags --always
> v1.3.0-rc1-14-ge9081ae
> $ git log --follow contrib/tuned/origin-node-host/tuned.conf
> There are a grand total of *two* commits that aren't mere
> code reorganization:
> commit d959d25a405bb28568a17f8bf1b79e7d427ae0dc
> Author:     Jeremy Eder <je...@redhat.com>
> AuthorDate: Tue Mar 29 10:40:03 2016 -0400
> Commit:     Jeremy Eder <je...@redhat.com>
> CommitDate: Tue Mar 29 10:40:03 2016 -0400
>     bump inotify watches
> commit c11cb47c07e24bfeec22a7cf94b0d6d693a00883
> Author:     Scott Dodson <sdod...@redhat.com>
> AuthorDate: Thu Feb 12 13:06:57 2015 -0500
> Commit:     Scott Dodson <sdod...@redhat.com>
> CommitDate: Wed Mar 11 16:41:08 2015 -0400
>     Provide both a host and guest profile
> That level of change seems quite sufficient for the slower
> RHEL cadence, no?

Decoupling profiles from RHEL has already been negotiated with many
different engineering teams.  As you can imagine, it has ties into our
channels and distribution mechanics.  Making an exception here doesn't make
sense to me when it's working fine everywhere else.

Particularly when one considers that something like the
> inotify watch bump could easily be part of a "tuned updates"
> in the installer that would live there until the base tuned
> profile updates.
> Right?

​Personally I would prefer to keep tuning centralized into tuned and not
have 5 difference places where it's being done...but to your point around
having two commits ... I'm losing that consolidation battle because
Kubernetes has hardcoded certain sysctl adjustments that ideally we really
should have carried in tuned :-/  But if we can at least avoid doing things
in openshift-ansible at least that's one less place to track.​

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

Realistically speaking -- we may want to use AH with another
product...we've developed
​realtime and ​
NFV profiles which again exist in another
channel and there is no such thing as openshift-ansible there.
What would be your approach if the openshift-ansible option did not exist?
(back to scattered tuning)​

Reply via email to