[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Having abrt on Atomic Host

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:

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 in
that regard.

I have 2 use cases here

A. Having abrt collect crashes from application containers
B. 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.html
abrt 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!


I 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 solution

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]