Re: [atomic-devel] Centralized Overrides?

[Jeremy Eder <jeder redhat com>]

----- Original Message -----
> From: "Colin Walters" <walters verbum org>
> To: atomic-devel projectatomic io
> Sent: Tuesday, May 12, 2015 8:55:31 AM
> Subject: Re: [atomic-devel] Centralized Overrides?
> 
> Hi,
> 
> On Mon, May 11, 2015, at 02:02 PM, Jeremy Eder wrote:
> 
> > - specialized selinux booleans (for use by NFS clients).
> > - specialized handling of LVM auto-extend (for use by
> > docker-storage-setup).
> > 
> > Instead, I think we should come up with a delivery vehicle for centralized
> > overrides.  This would provide analogous functionality to tuned (where we
> > centralize tunings).  This is similar in concept to "alternatives".
> 
> In Fedora 21, the products can now contain variant-specific defaults, such as
> having
> the firewall rules be different between a Server and a Workstation install.
> 
> See: https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration

Cool, that's part of it.  Seems fairly new, and don't think this trickled into RHEL at the moment.  Perhaps a RHEL8-ish discussion...

> Or another example which presaged it:
> https://bugzilla.redhat.com/show_bug.cgi?id=978081
> 
> So for whatever it is we want to change, I think it's best if the relevant
> subsystem
> has the ability to configure via "drop in" files.  With priority rules and
> clearly
> specified semantics in the case of multiple overlapping drop-ins.

Agreed, OK.
 
> SELinux booleans, for example, have no such facility AFAICS =/  But that
> doesn't stop
> us from adding it.

Right, actually dwalsh suggests we do this in a Kube unit file.  We can perhaps go one step further and put it into the Kube code that goes and mounts the NFS stuff, to make sure we only turn it on when absolutely necessary.  The problem with the Kube approach is it doesn't account for Docker.  So, do we turn this on in the Docker unitfile?

> Failing the above though, there are two places to make changes:
> 
>  - As part of the tree compose:
>  https://git.fedorahosted.org/cgit/fedora-atomic.git/tree/treecompose-post.sh
>  - As part of the kickstarts:
>    *
>    https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/atomic-installer/lorax-configure-repo.tmpl
>    *
>    https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-atomic.ks

We need to account for RHEL users though.

> > Tuned provides "profiles" for optimizing different workloads.  Over time, I
> > could see this centralized overrides approach growing in scope across
> > products.  It's also quite possible that tuned could be extended through
> > plugins to fill this need.
> 
> My initial thoughts here are that it would make sense for tuned to remain
> focused on performance, although the default profile might be product or
> variant specific.

I agree with this, I only mentioned plugins for completeness.  Although inevitable, I would prefer limited scope-creep on tuned.
 
> For example, you can have Atomic as both "powersave" or "network-latency",
> right?

Yeah, there are so many permutations of that problem.

> > Override functionality could also play a role when a layered product (RHEV)
> > needs to, but doesn't want to, have to add packages to the Atomic base
> > package list.  IOW alternatives specifies a layered product's own
> > container, and that gets pulled into the system by this new overrides
> > method either at build- or run-time.
> 
> I'm not sure where you're going with this last part; if a privileged
> container wants to drop in files on install to change the host's config,
> assuming we support drop-in files for whatever the app wants to do, that
> should be sufficient, right?

Let me re-phrase, this is not about SPC.  I was trying to discuss a way for layered apps to "not care" about if they're on Atomic or not, when it comes to specifying their "Requires".  IOW a "requires" could be satisfied by a container, just as well as an RPM.  Sorry for conflating 2 totally different subjects in one mail.