Toolbox: [RFE] Introduce a command to recreate a toolbox

[mildred]

With toolbox improving, the podman create command-line within toolbox improves with new volume mounts. Old toolbox created with older versions of fedora-toolbox are not updated to the latest features automatically.

It would be great if there was a way to keep the old toolbox files, and create fresh toolbox containers from them. Something like podman commit && podman create. Or perhaps podman can be improved to update the properties of a stopped container (volumes, environment vars, uidmap, security options, ...)

On my machine, I could not run successfully a podman commit (either I had errors, or it takes too long and too much IO resources) else I would have made a pull request already. If there are podman gurus out there, perhaps a feature like that is not that difficult.

[mildred]

Possibly using podman config can update a non running container to aovid having to recreate the container from scratch.

[cjao]

In a similar vein, how about also caching the dnf metadata? Otherwise, with every container created one has to download the same metadata for the main Fedora repository, which doesn't change after the distribution is released and weighs in at 60mb over the wire.

[debarshiray]

One problem is that it's cumbersome to add new volume mounts to an existing OCI container using Podman. See https://github.com/containers/libpod/issues/1320

But, yes, I agree that this is a valid problem.

[debarshiray]

In a similar vein, how about also caching the dnf metadata? Otherwise, with
every container created one has to download the same metadata for the main
Fedora repository, which doesn't change after the distribution is released and
weighs in at 60mb over the wire.

Caching the DNF metadata would be bad idea. We used to do that by mistake, which was fixed in commit 16f0b21ebc1de9562faad350002a79fecb4d49ef.

Generally, the metadata does change. eg., if you layer an image on top of an image with a stale DNF cache, then you would run into errors caused by broken URLs pointing at missing RPMs.

We could try to preserve the metadata for specific repositories which really won't ever change, but I don't know if there's a DNF command to do that. It's probably not worth the trouble.

[cjao]

I agree that retaining the metadata in the image is a bad idea. What if one were to mount a common "md-cache" folder on the host to each container's /var/cache/dnf at runtime, something like "-v $HOME/.local/share/toolbox/rpm-md/fedora-[release]:/var/cache/dnf"?

[tigerpaws2]

I managed today to create a new toolbox based on an existing one:
I did the following, given a running toolbox (but not currently 'entered') called ansible:

podman stop ansible
podman commit ansible ansible2 (takes a while)
toolbox create -c my_ansible -i ansible2
toolbox enter -c my_ansible 

Then I had a a new toolbox with ansible pre-installed. If I failed to do the podman stop, when I tried to enter the new container, I got the following error message:

invalid entry point PID of container my_ansible

It seems to me that maybe we could simply have a toolbox command that does all the above in one shot.

[debarshiray]

I managed today to create a new toolbox based on an existing one:
I did the following, given a running toolbox (but not currently 'entered') called ansible:

[...]

It seems to me that maybe we could simply have a toolbox command that does all the above in one shot.

Let's use https://github.com/containers/toolbox/issues/462 to discuss this.

[debarshiray]

I wonder how relevant the original issue still is ...

With toolbox improving, the podman create command-line within toolbox improves
with new volume mounts. Old toolbox created with older versions of fedora-toolbox
are not updated to the latest features automatically.

It would be great if there was a way to keep the old toolbox files, and create fresh
toolbox containers from them. Something like podman commit && podman create.
Or perhaps podman can be improved to update the properties of a stopped container
(volumes, environment vars, uidmap, security options, ...)

Ever since we introduced the toolbox init-container command, we have been steadily moving a lot of the bind mounting into it from the old approach of doing it at podman create. In fact, containers that are too old to have toolbox init-container as their entry points are now deprecated and not supported in the re-written Go version.

This lets old containers pick up new bind mounts introduced in newer versions of Toolbox, which is a big part of what this issue is about.

Granted this doesn't let old containers pick up every possible improvement, but it does solve the issue of bind mounts to a very large degree.

[debarshiray]

I am tempted to close this.

[bam80]

Why is that? No horsepower to push it forward?

[HarryMichal]

I personally don't know of a way how this could be implemented in a way that doesn't require Toolbox to be rewritten as a whole and that does not rely on distro-specific integrations (e.g., in dnf, apt, pacman,..).