Re: [atomic-devel] Breaking up our tools container image

...
So, given that this is a concern for upstream, I support breaking up the
image into logical parts.

Additionally, what about basing each image on RHAtomic Image and/or
Fedora/CentOS minimal image? That might bring the size down further,
altough it's possible that the packages involved would just re-install
all of that content anyway.

Yeah I've played w/ this quiet a bit. The rh atomic base images & fedora-min work really when you're pulling in a handful of packages. Anyway package that is really heavy on deps, rsync comes to mind, is not a good fit and might as well use the regular base image. The docs example container I built was a perfect use case for it.

> 1) Drop all packages from rhel-tools that exist only for documentation
> purposes. [1]

+1 on the idea, I don't understand your paste output though.

Sorry these are just packages that either are on atomic host (or used to be) and are also in the container so the man pages are available when using atomic host. If we carve out a docs container, we no longer need to include these in the dockerfile for the tools container (systemd & yum are listed just so the docs get installed).

> 2) Trim down the included packages to this list: [2]
> Basically leaves the full capabilities and results in a 476M image which
> is a huge step in the right direction.

No objections in general. We might want to look at breaking this down
further into six contianers:

- build-tools (gcc, git, glibc etc)
- debug-tools (ltrace, gdb, crash, sos, etc.)
- cli-tools (which, bash-completion, tar, etc.)
- admin-tools ( parted, passwd, pciutils, xfsprogs, etc.)
- net-tools (net-tools, ethtool, tcpdump, etc.)
- perf-tools (perf, sysstat, systemtap, etc.)

I'm not opposed to this, but, is this overly granular? For example collapsing cli-tools, admin-tools, & net-tools into a single admin-tools image might be simpler in the end. Finding the balance of things like this sets off my OCD.

> 3) Create a dedicated image for sosreport utilities.
> Includes redhat-support-tool, sos, & strace and depending on which base
> image we use it’s either 120M (rhel7-atomic) or 212M (rhel7)
> This may only be appealing on the rhel side of the house, but if there’s
> value for fedora & centos, it would be trivial to also offer it.

sos & strace have appeal, redhat-support-tool less so. For Fedora and
CentOS, I would tend to see those as going into the general tools
package in (2), but don't have strong objections to it being its own
container.

Yeah this was brought up by support, and something they would like to see happen. The only other advantage to this being a dedicated and consistent image is for cockpit. Using the sosreport app in cockpit would be faster and pull a dedicated & consistent image across rhel,cent, & fedora. I'm sure they could work around it, but this might justify having it. Thoughts?

>
> 4) Optionally create a man pages container.
> I really want feedback to see if anyone thinks this is useful. RPM & yum
> provide a nodocs capability, but they lack a docs only setting which is
> what we need. It works quite well to tar up the man-db for our existing
> rhel-tools image and inject it in our minimal base image. This results
> in a docs only container that’s ~100M on disk. It would be a slight
> hacky process to release something like this, but we could do it. I just

I'm in favor of a man pages contianer, but it might violate FLIBS policy.

I'll bounce it off Adam and see what he thinks.

Thanks for the feedback on all this!

--
--
Josh Berkus
Project Atomic
Red Hat OSAS

Ben Breard

Sr Technology Product Manager - Linux Containers

Mobile: 972-816-9081