[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] Breaking up our tools container image
- From: Brian Exelbierd <bex pobox com>
- To: atomic-devel projectatomic io, Matthew Miller <mattdm fedoraproject org>
- Subject: Re: [atomic-devel] Breaking up our tools container image
- Date: Mon, 03 Jul 2017 12:56:49 +0200
+mattdm
On Fri, Jun 30, 2017, at 12:35 AM, Josh Berkus wrote:
> On 06/27/2017 02:01 PM, Ben Breard wrote:
> > Today we ship a “tools” container that’s *really* large, specifically
> > it’s about 1.5 GB on disk. The feedback I’ve gotten from users is that
> > it's too large to be useful and they try to avoid it. This of course
> > makes me sad and I think we should take another look at it. Primarily
> > this container contains debugging, performance, support utilities
> > (sosreport), as well as man pages for packages only shipped on Atomic
> > Host. I think splitting it up along these lines makes sense and will be
> > intuitive for users. That said, there’s a fine line between some of the
> > debugging and performance tools, so after looking at the package list, I
> > think it makes sense to keep those together in the “2.0” tools container.
> > Here’s what I’m proposing and would love feedback on:
>
> 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.
>
> > 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.
>
>
> > 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.)
Matthew is working on tools modules for Fedora Modularity. It might
make sense in many cases for these things to be similar.
regards,
bex
>
> > 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.
>
> >
> > 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.
>
>
> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]