> > 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 On Mon, May 11, 2015 at 2:02 PM, Jeremy Eder <je...@redhat.com> wrote: > Hi, > > Since RHEL Atomic descends from RHEL (and same with CentOS/Fedora), we > inherit some defaults in a growing list of areas that don't make sense for > a specialized container distribution. We resolved many of the performance > issues in the last year or so, using the tuned profile delivery vehicle. > 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). > > 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". > > 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. > > 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. > > 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. > > Are there plans for this already? Does anyone know of an existing > mechanism that offers this feature? > >
