> >> > >> 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? > >> Dusty > >> > > 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. It adds more moving parts, which can break and affect the system. Simplicity is key to any successful endeavour. On one end you have "container everything" On the other you have 'just use rpms' I think the right answer is somewhere between. Admins of an atomic fleet likely just want tools that "work" and are right there. But containers are there for higher level applications. And is it really worth our effort? I see hours of work going into the sssd container - now sssd is just part of base atomic. Was that really worth the extra hassle? Now contrast this to LDAP server - that does *not* belong in the base, and *IS* worth the effort to containerise. As engineers we LOVE our toys, and when you have a hammer everything looks like a nail - right now that's how I think we are approaching this. Really, we need to say "what's the right tool here", and that balanced approach will pay off because we use the "best of both worlds"> > > > > 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. > > > > > 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. > We should be showing this with *larger* applications - This is why I'm working to put 389 Directory Server in docker for example, but I won't put ldap client tools in a container. Not worth my time. -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part