always offer to pull latest image when creating a toolbox

[juhp]

Is your feature request related to a problem? Please describe.
We frequently see bug reports caused by people having an old toolbox image cached locally.

Describe the solution you'd like
toolbox create should offer to pull down the latest image being requested.
For extra points it could check if a newer image exists first.

Additional context
I am imagining something like this:

$ toolbox create
A newer fedora-toolbox:34 image is available, do you want to download it? [Y/n]

I think this is the least surprising behavior (though personally I would always want to pull the latest image).

[juhp]

Implemented in #875

[HarryMichal]

A large number of images can accumulate this way. Disk space is not so expensive nowadays but say 10 images will take up circa 5GB on a system.

But generally I agree with you that this is a concern and I have a solution in mind that pulls in the latest images and also migrates older containers to those images. I have yet to create a prototype and address some concerns regarding the approach, though.

I'd be willing to go with this before my solution is done but I'd like to make also some changes to the way images are listed. The list of images could get very long. I think (did not test locally) #875 is a bit naive solution and could be more harmful than helpful, though.

[juhp]

A large number of images can accumulate this way. Disk space is not so expensive nowadays but say 10 images will take up circa 5GB on a system.

You are right: it would be better to purge older unused toolbox images.

But generally I agree with you that this is a concern and I have a solution in mind that pulls in the latest images and also migrates older containers to those images.

That sounds very interesting. How would that be possible?

I'd be willing to go with this before my solution is done but I'd like to make also some changes to the way images are listed. The list of images could get very long. I think (did not test locally) #875 is a bit naive solution and could be more harmful than helpful, though.

Okay sure: looking forward to seeing more

[HarryMichal]

That sounds very interesting. How would that be possible?

I have a theory that is only a theory now. When I have a prototype, I'll let the community know :). Maybe it will work and maybe it will not.

[debarshiray]

We frequently see bug reports caused by people having an
old toolbox image cached locally.

Umm... do you have some examples of these bug reports?

I know that people struggle to switch from Rawhide to a freshly branched unstable Fedora at the branching point. Anything else?

Have we ever pushed out badly broken images for stable Fedoras? Ultimately users can always 'dnf update' their containers, can't they?

[juhp]

I will have to go hunting for examples: there should be enough around.

Conversely, why would you not want to create a new toolbox with the latest image?
(Also filesystem can't be dnf updated.)

[debarshiray]

(Also filesystem can't be dnf updated.)

This one is #643, which should be fixed now.

[debarshiray]

Conversely, why would you not want to create a new toolbox with
the latest image?

If there were no other trade-offs, yes, I would always want to use the latest image.

However, if a user keeps accumulating a large number of images, then:

• It can negatively impact disk space.
• It can clutter up the toolbox list output and make it difficult to get a feel for what images are locally available.

These are trade-offs, and we need to figure out what the right balance is. That's why I was curious about examples of bugs caused by stale images.

There could be other ways of looking at this too:

• Sharing the DNF caches to reduce network traffic.
• Prompting the user that a new image is now available, so that they can manually migrate.

[oturpe]

We frequently see bug reports caused by people having an
old toolbox image cached locally.

Umm... do you have some examples of these bug reports?

I know that people struggle to switch from Rawhide to a freshly branched unstable Fedora at the branching point. Anything else?

Have we ever pushed out badly broken images for stable Fedoras? Ultimately users can always 'dnf update' their containers, can't they?

1. At a time when toolbox:36 image is Rawhide,
2. need a Rawhide toolbox, get it with toolbox create --release 36.
3. Time passes, Fedora 36 is branched and toolbox:36 is re-defined to mean that.
4. Need a Fedora 36 toolbox, try to get it with toolbox create --release 36.
5. Expected result: get a Fedora 36 toolbox
6. Actual result: get a Rawhide toolbox

The image was not badly broken at the time is was created,
just had a confusing name,
but the resulting container in step 4 is badly broken,
because dnf does not point to repositories of the requested release.

I have reported this before in this comment.
Would you like to have this logged separately also?

Apart from automatically pulling, or prompting for pulling, new images,
this could also be solved through #646.

[debarshiray]

Switching from Fedora Rawhide to Branched is already a known and understood issue (and isn't specific to containers). I was looking for other problems that we have come across over time.

[oturpe]

Switching from Fedora Rawhide to Branched is already a known and understood issue (and isn't specific to containers). I was looking for other problems that we have come across over time.

My example is not about switching from Rawhide to Branched.
At step 2, the user needs, and gets, a new Rawhide container.
It can stay Rawhide forever without affecting the rest of the steps.
At step 4, the user needs a new Fedora 36 container.
At this point, they are not interested in Rawhide at all.
But because Toolbx
a) first defines --release 36 to mean Rawhide, but later re-defines it to mean Fedora 36, and
b) does not pull latest images on create,
the user unexpectedly gets Rawhide in step 4.

Doing what is proposed in this issue would fix b),
fixing #646 would fix a).
Fix one, and the problem disappears.

EDIT: Ok, if you by "switching from Rawhide to Branched" mean
what I mean by "re-defines it to mean Fedora 36",
then indeed this is caused by that.

[debarshiray]

Yes, #646 is a much safer change to implement.