Re: [atomic-devel] Centralized Overrides?

[Colin Walters <walters verbum org>]

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

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.

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

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

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

For example, you can have Atomic as both "powersave" or "network-latency", right?

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