proposal: Dnf cache between containers

[juanje]

Hi!

Disclaimer: This is just a proposal, but with initial implementation as a PoC. I tried to mimic the code and be the least intrusive as possible, but I'm sure that it can be improved.

The idea

Toolbox is a very useful tool for developers and the fact that create quickly dev environments that can be destroyed is awesome. But when you work with different containers or destroy-and-create containers frequently, you might want your packages cached, so the new container's provision doesn't take long.

Also, some people work in environments with limited Internet connection.

That's why I think it'd be good idea to create external (to the containers) cache for the packages, so it can be shared between the containers and you don't need to download again and again the same packages.

Inspiration

I've used a lot Vagrant with vagrant-cachier and saved me plenty of time and bandwidth.
Also, I read this article recently and it makes think about dong something similar for Toolbox:

Speed up container builds with overlay mounts

Some considerations

The external cache is located at: ~/.cache/toolbox/{release}
The location ~/.cache/{APP_NAME} seems to be the standard for modern application's user's caches. I added the {release} subdirectory to avoid share dnf's caches between containers from different releases and mess it up.

I noticed that dnfremove the packages after the installation, so I add the option keepcache=True to the config file /etc/dnf/dnf.conf at the Dockerfiles for the different Fedora images. Otherwise, the shared cache would be a bit useless.

[softwarefactory-project-zuul]

Build failed.

• shellcheck : SUCCESS in 2m 20s
• system-test-fedora-31 : SUCCESS in 3m 54s
• system-test-fedora-32 : SUCCESS in 3m 25s
• system-test-fedora-rawhide : FAILURE in 3m 23s

[HarryMichal]

Hi @juanje! I also read the article and I've been thinking of adding such feature to Toolbox. Thank you for working on this!

Since v0.1.0 is not out yet and we'd like to make as stable as possible without adding any new features, I add this to the 0.2.0 milestone.

~/.cache/toolbox/ is a good location but I'd exchange {release} with {distro-release} because even though Toolbox officially supports only Fedora the intention is to support even other distros.

I'm not sure about the keepcache=True option, though. If I'm not mistaken then without that option /var/dnf/cache only keeps repo metadata, right?? Is that not enough?? Also, do we want to add this to the list of requirements that a toolbox image should fulfil?? I think this is something that could be handled by the entry-point - toolbox init-container.

Another thing, Toolbox currently does not work if it is run with sudo or as root because of flatpak-session-helper but I believe that is something that we aim to fix in the future. When that situation comes, this code will need adjusting because the shared cache for dnf and others for a rootfull container can not be stored in a user's home directory. So, some kind of logic for setting something like a toolboxCacheDirectory will be necessary. But that is currently not a big deal, I'm just writing this that we're aware of the fact.

[juanje]

Thanks for reviewing the PR 😄

Since v0.1.0 is not out yet and we'd like to make as stable as possible without adding any new features, I add this to the 0.2.0 milestone.

That makes a lot of sense 😄

~/.cache/toolbox/ is a good location but I'd exchange {release} with {distro-release} because even though Toolbox officially supports only Fedora the intention is to support even other distros.

I was thinking the same, but I wasn't sure about how distro agnostic Toolbox really was (or wanted to be).
Definitively, it makes more sense {distro-release}.

I'm not sure about the keepcache=True option, though. If I'm not mistaken then without that option /var/dnf/cache only keeps repo metadata, right?? Is that not enough??

Well, IMO the big advantage of having this feature is to download the packages just once and reutilize them from each container from the same distro-release. This way, you save a lot of time and bandwidth. But without this option, every time you install something, the package gets removed, so the cache doesn't do much.

I tried first without the option and each container downloaded the same packages every time. Then, I added the option and it just downloaded the first time, the rest each container just used the downloaded packages.
A lot faster.

Also, do we want to add this to the list of requirements that a toolbox image should fulfil?? I think this is something that could be handled by the entry-point - toolbox init-container.

Sure. I don't know well all the code and that part is the least I know hehe
But looking the code I guess that would be the right place. It's definitely better not to have a long list of prerequisites for the toolbox images.

Although I know this is going to be on hold until the milestone 0.2.0, I'll look into it to understand better the code and where it could fit at the toolbox init-container.

Another thing, Toolbox currently does not work if it is run with sudo or as root because of flatpak-session-helper but I believe that is something that we aim to fix in the future. When that situation comes, this code will need adjusting because the shared cache for dnf and others for a rootfull container can not be stored in a user's home directory. So, some kind of logic for setting something like a toolboxCacheDirectory will be necessary. But that is currently not a big deal, I'm just writing this that we're aware of the fact.

I probably miss out more user cases. This was a naive attempt to have a working PoC, but I'm aware that it needs some thinking.
I'm glad it's in the roadmap and I'll help any way I can.

[HarryMichal]

I just realized there was a similar PR in the past. Putting it here for reference. #239