Rename "Container Wrapper" section

[Danzelot]

"Container wrapper" does not reflect the intentional use. Also it sounds a bit like you have a container wand want to get it wrapped. Something more descriptive to tell users what the tool is used for and not just what it does.

Can't really think of a good title at the moment.

[Chroxvi]

I agree. I think the current name is misleading to most users since it kind of implies that you have to know about - and use -containers to use the container wrapper. Actually, the whole point in using the container wrapper is that you don't have to deal with containers...

I don't really have an idea for a good name, so here are some thoughts about the container wrapper - hopefully it can inspire someone else to come up with a great name for it.

First a few thoughts about what it tries to achieve

Looking at the description of the tool on the on the LUMI docs

The container wrapper is a set of tools which wrap software installations inside a Apptainer/Singularity container to improve startup times, reduce I/O load, and lessen the number of files on large parallel file systems.

it is clear that the container wrapper is actually:

• a set of tools: It provides "frontends" for multiple use cases, i.e. wrapping conda/pip environments, wrapping existing containers, wrapping any installation on disk - see https://github.com/CSCfi/hpc-container-wrapper#implemented-frontends for details.
• to improve startup times, reduce I/O load, and lessen the number of files on large parallel file systems: <-- This is the reason you would want to wrap an installation.

Also, it is implicitly given that the container wrapper does this in a way that is hidden from the user, i.e. the ignorant user experience is:

1. I usually run /my/software/bin installed on the file system.
2. I wrap /my/software/ using the container wrapper.
3. Some "magic" folders appear on the file system - I just ignore these
4. I run /my/software/bin as usual, and suddenly I enjoy improved startup times and reduced I/O load.

Then a few thoughts about how it achieves it

The container wrapper basically works by:

1. Making a squashfs image containing /my/software
2. Pulling a basic Singularity/Apptainer container image (on LUMI its an OpenSUSE Leap image)
3. Replacing all scripts/binaries under /my/software with a set of other scripts that instead of calling the script/binary directly, runs the pulled container image using SIngularity, mounts the squashfs image in the container and runs the corresponding script/binary from within the squashfs image.

So even though the container wrapper uses containers to achieve its goal, it is fully hidden from the user.

And then a list of words that I associate with this tool

Here are some of the words I would maybe associate with what the container wrapper tries to achieve:

• Wrapping: It covers/surrounds the installation
• Squashing: It squeezes the installation into something suitable for shared file systems
• Achieving: It stores the installation in an archive, though archiving may sound a bit like it is never going to be used again
• Compressing: It squeezes the installation into something suitable for shared file systems, though, technically, no compression of the data happens.
• Wrangling: It transforms the installation into something suitable for shared file systems

And finally a wrap-up

I think we can either use the actual name of the "container wrapper", i.e. "Tykky" or try to come up with a name that describes what it tries to achieve. My best suggestion is "Installation Squasher", though that probably sounds a bit too destructive...

For more context on how the container wrapper works and how it compares to cotainr see https://github.com/DeiC-HPC/cotainr/issues/37

@Nortamo please chime in, if you think I got the above description wrong in any way.

[Danzelot]

Thanks for the great feedback. I agree that we should focus on the goal.

My problem with Tykky is that it does multiple things at once which makes it very hard to describe in one concise expression that user will understand. So my suggestion is to just call it something like "Installing python packages" or "Using conda/pip". The part about wrapping container should be separated into its own section; maybe under containers where we could describe the advantages of using Tykky and not just a pure container.

I feel like that way we can focus on the intended usage and not the tool.

[hdrei]

I would also like a heading something like "Installing python packages" or "Using conda/pip". These describe the (main?) usage of the "Container wrapper" tool, and by these names it would be clear for the 'target audience' that this tool does what they are looking for. One option would be to have a (sub-)heading something like those that just shortly describes the usage of it for these instances, beside a heading that describes what the "Container wrapper" tool is and what all it can be used for.

"Container wrapper" is definitely not a good name. Some thoughts/suggestions what to call the section instead. The best names I could think of would easily be too long, and these are the best ones I'm able to come up with with the same idea that are short enough:

• Installation wrapper
• Installation compressor
• Filesystem friendly installation
• Lustre friendly installation
• Reducing software filesystem load
• Reducing filesystem load
• Reducing software I/O load

[Chroxvi]

So my suggestion is to just call it something like "Installing python packages" or "Using conda/pip". The part about wrapping container should be separated into its own section; maybe under containers where we could describe the advantages of using Tykky and not just a pure container.

This makes me wonder if we should not have a dedicated section for the "container wrapper", but instead describe its usage where relevant, e.g. as part of a section on "Installing Python packages", as part of running container jobs, and as part of some "IO optimization section".

@hdrei and I have created a plan for writing some documentation on "Installing Python packages", i.e. a major rework of the stale #24. We ended up counting 12 different ways to "install" Python packages on LUMI (including various ways to run Python containers). The "container wrapper" accounts for 2 of these (conda-containerize, pip-containerize) and is a great choice for some applications. For other applications there are IMO better options, which is why I am hesitant to use "Python", "Conda", or "pip" in a new name for the "container wrapper". I would ideally like something that doesn't suggest that this is the way to install conda/pip environments on LUMI. But maybe that is too ambitious.

[Chroxvi]

An attempt was made at renaming the LUMI container wrapper in #127. However, the suggested change didn't make it in that PR. See https://github.com/Lumi-supercomputer/lumi-userguide/pull/127/commits/2b8506f483fb5b66d5b7644f6ff797e3c95d8d6d for more details about the suggested change.

[hdrei]

In case the name of the container wrapper is changed later, it should also be taken into account that the current name exists in teaching materials, and schedule the name change according to that

[Danzelot]

I think we can close this issue for now and if necessary pick it up again at some point.