Mark image for pruning

[ygalblum]

I have a use case in which I would like to pull a new version of an image, but not use it until reboot (or an explicit service restart). As a result, since the image may be currently in use, I cannot remove the old image during the same process.

Podman offers an images prune command that may be used to remove dangling images or even all unused images (by passing --all). But, removing all unused images is not the right solution in an environment with limited connectivity as it might remove images that will be used in the future, just not at the time prune is called.

Alternatively, the prune command also supports a filter argument to prune only the images containing certain labels (or label=value). However, labels are set during the creation of the image and cannot be altered. So, this path is blocked.

So, I would like to add a command that will mark images for removal and then an option to prune to remove such images.

[Luap99]

If you know what image you want to remove, is there any reason to not just call podman rmi on it?

[ygalblum]

The reason I can't call podman rmi is that the call will fail if the image is in use at the time that I'm pulling the new version.

I'll give an example:

Let's assume my Quadlet file is:

[Container]
Image=ygal:0.1

So, podman will be running the ygal:0.1 image.

Now, let's say I would like to upgrade by pulling the new image ygal:0.2 and updating my Quadlet file accordingly:

[Container]
Image=ygal:0.2

However, I do not wish for the upgrade to happen at the time that I'm pulling the update, but only after reboot (or after the user explicitly ask for it). Please keep in mind that changes to the Quadlet file are not processes by Quadlet until either a reboot or a call to systemctl daemon-reload.

So, when my update phase is complete, I have both images locally, ygal:0.1 is in use and ygal:0.2 is ready to be used after the reboot. As a result, during the update phase, calling podman rmi will fail. Once a reboot happens, Quadlet will process the updated file and ygal:0.2 will be used. ygal:0.1 will stay there without anyone knowing it should be removed.

So, what I am suggesting here is the ability to mark ygal:0.1 for pruning and the ability for images prune to remove only the images marked as such.

I think the alternative will be to implement this mechanism separately. That is, maintain a list of images marked for pruning and have a process run podman rmi on them. But, I think having this ability baked into podman is more natural

[Luap99]

Yeah I am generally fine with a containers.conf approach. I am personally not too concerned about performance either, I just bring this up because automotive is.

Second, maybe I was missing the point that you want to install these files as rpm. I thought you want make quadlet create the files for each container unit?

---

Maybe a different direction, have you thought about making podman prune parse the quadlet files and ignore the images in there. This would make it work without any new extra files and all quadlet users could use it not just the files that are shipped via packaging.

[vrothberg]

Second, maybe I was missing the point that you want to install these files as rpm. I thought you want make quadlet create the files for each container unit?

It's not necessarily tied to automotive where images would be part of the ostree image and pre-installed. The use case is to ship containerized services as Quadlet files via RPMs. I understand that's it's still WIP but the task was to find a way to prevent images from accidentally being pruned from the machine when an installed RPM is depending on it. Declaring that in a config file seemed like a straight forward and easy to support way of achieving that.

Maybe a different direction, have you thought about making podman prune parse the quadlet files and ignore the images in there. This would make it work without any new extra files and all quadlet users could use it not just the files that are shipped via packaging.

We discussed the idea of image prune parsing the Quadlet (and Kube) files. One downside is that it's easy to regress: new functionality in Quadlet may require extending the prune logic.

[Luap99]

It's not necessarily tied to automotive where images would be part of the ostree image and pre-installed. The use case is to ship containerized services as Quadlet files via RPMs. I understand that's it's still WIP but the task was to find a way to prevent images from accidentally being pruned from the machine when an installed RPM is depending on it. Declaring that in a config file seemed like a straight forward and easy to support way of achieving that.

OK yeah this makes a sense then. Shipping them as rpm under /usr/share... should work just fine for this. With that knowledge I agree with the proposal to add a new containers.conf field and let the packagers/admins deal with adding the correct images there.

[vrothberg]

Since the need to mark images as unprunable came up recently, I want to highlight this conversation:
Cc: @rhatdan @baude @mheon @cgwalters

[cgwalters]

AFAICS this is (almost) exactly the same thing as containers/bootc#128

The (almost) is just around the detail of having multiple root filesystems in the bootc case, which doesn't exist in the package-based (apt/dnf) case.

[rhatdan]

Parsing the quadlet files would not be enough, you would also need to parse the kube.YAML files. It would quickly get out of control. We might have to deal with additional stores as well.

I think potentially adding a last time used date to RW images could come in handy. Might be useful for all users, what images are in my store that have not been used in one month, year, decade.