But there are others appearing now that might not fit in tuned, whether it's for technical (build tooling) or political reasons. At least:
- specialized selinux booleans (for use by NFS clients).
- specialized handling of LVM auto-extend (for use by docker-storage-setup).
Not having insight into the reasons, can you elaborate on the fix? Are you adding new tunables to policy as a result of Atomic or are you changing the defaults in the policy booleans? Same with LVM, did it require a different package or configuration? I'm guessing config based on the rest of the email but I'd like to be clear.
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.
Agree with Colin, layered products can't and shouldn't modify the base package list but be delivered as a container. Also, do you a reason why multiple layered products couldn't reside on the same Atomic host? Having a complete system wide override on a per layered product could cause conflicts. I'm thinking Kolla and OpenStack services on Atomic hosts.
Does anyone know of an existing mechanism that offers this feature?
Augeas? If this is a matter of having a mechanism to change base Atomic config files on a per RHEL Family basis (not a per container role basis), then wasn't that the purpose of Augeas? I'm not sure what the current status / use of the tool is.
The end goal here might be a single, very small Atomic distro, and a family of override profiles that are the consolidated place for customizing variants of our products.
If it's package binary issues, then I think that the differences between RHEL and RHELAH would need be handled via another mechanism, something that dovetails with the existing build process. Guess I'm not clear on how the existing compose mechanism doesn't provide different profiles based on source family.
-Matt M