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

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



+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]