On 05/30/2017 06:29 AM, Daniel Walsh wrote:
Lastly, if we don't show use cases where distribution packages are shipped in system containers, then others people wanting to ship software will continue to fallback on the traditional RPM based installs.On 05/29/2017 11:57 PM, Dusty Mabe wrote:On 05/29/2017 08:20 PM, William Brown wrote:On Wed, 2017-05-24 at 11:44 -0400, Daniel Walsh wrote:On 05/19/2017 01:46 AM, Niranjan M.R wrote:Greetings,I would like to know what is the status of having Abrt on Atomic Host. I see there was a old thread[1], but could not figure out if there was any work being done inthat regard. I have 2 use cases here A. Having abrt collect crashes from application containersB. Having abrt collect crashes of process running on Atomic hosts (like docker).Any update on the above would be helpful.1. https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-February/msg00026.htmlabrt should be packaged as a System container.That doesn't seem right. I think that while we should have the goal to containerise things, there is a point where *too much* is reached. I think this is a good example (as is SSSD) atomic host should have "just enough" to make running containers a good system, and being able to admin them effectively, but without *over complicating* the system. I think that shoving everything (like abrt, sssd) in containers is a mistake because these are clearly in the atomic layer, and there is no benefit to the complexity of containerising them. * Do I need abrt to move at a different rate to my atomic base (no) * Does containerising it have a tangible benefit over non (no) * Does it add complexity (yes) Rather than living at extremes, we should be taking a more reasonable approach to this design I think.I tend to agree here. Previously things had to go into either the base atomic host or they had to go into a container. Now we have package layering, so there is a middle ground. I say let's keep the base relatively small like what we have today. For things that are low level utilities/services we can either choose to include them in the base or not. If not the user still has the option of layering them in using `rpm-ostree install pkg`. With the livefs work that is going on upstream we might even be able to rid ourselves of the dreaded reboot for package layering. For higher level services and applications container(verb) away! Thoughts? DustyI am fine with layering it or installing it as an system container.But I would argue against the differentiation about low level tools being installed as container images.I believe the future is container images and having precanned system container images is an excellent solutionto loots of tools that you want to use to enhance the atomic host.Realize that just because a piece os software is installed as a system container does not mean it needs to use ANY container technology.Running software using systemd technology to run the software as a chroot is fine. Executing one command inside of the container is fine.A system container is JUST a way to deliver bundeled software from a Container Registry to a host, as opposed to delivering it in an RPM where it would require deep bundling with the host.