Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host

On Fri, Oct 14, 2016 at 7:40 AM, Jeremy Eder <jeder redhat com> wrote:

On Wed, Oct 12, 2016 at 10:29 AM, Colin Walters <walters 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 <jeder redhat com>

AuthorDate: Tue Mar 29 10:40:03 2016 -0400

Commit:     Jeremy Eder <jeder redhat com>

CommitDate: Tue Mar 29 10:40:03 2016 -0400

    bump inotify watches

commit c11cb47c07e24bfeec22a7cf94b0d6d693a00883

Author:     Scott Dodson <sdodson redhat com>

AuthorDate: Thu Feb 12 13:06:57 2015 -0500

Commit:     Scott Dodson <sdodson 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.

Given the reboot issue gets addressed, I think I would prefer this approach as well. We are working as best as we can to decouple the underlying host management from the cluster management especially around upgrades. Being able to update and ship the tuned profiles as needed would allow us to manage it as part of the cluster management without having to query underlying host state to determine if we need to do temporary modifications. The other issue is that we don't require users to manage their environments with Ansible, so our temporary modifications would also need to be documented and implemented separately for non-Ansible users.

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.

I can understand why Kubernetes wouldn't want to require tuned, but maybe we can drive changes upstream to make sysctl management optional. Then we would be able to add the tuned requirement in our packaging and handle it there without forcing tuned upstream.

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)

Jason DeTiberus