----- Original Message ----- > From: "Matt Micene" <nzwul...@gmail.com> > To: "Jeremy Eder" <je...@redhat.com> > Cc: atomic-devel@projectatomic.io, "Vivek Goyal" <vgo...@redhat.com> > Sent: Tuesday, May 12, 2015 9:36:16 AM > Subject: Re: [atomic-devel] Centralized Overrides?
> > 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? NFS is blocked by SELinux right now. > 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. LVM's default config/policy disables auto-extend. We are considering a case where we enable that. > > 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. I replied to Colin's email elaborating on what I meant, I did a poor job in describing the idea. > > 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? >
