Hi Kristoffer, On 1/14/26 18:00, Kristoffer Balintona wrote:
What I mean is having the images themselves within the store such that images are a part of roll backs and are upgraded with the rest of the system.
All image kinds already (somewhat) support rollbacks. Suppose you are using docker.io/bitnami/grafana:12.0.0 to back a Grafana service. Once you decide to upgrade to 12.0.1, you change the image field of a oci-container-configuration to docker.io/bitnami/grafana:12.0.1 and reconfigure your system. You now have two system generations on your machine, one with Grafana 12.0.0 and the other with 12.0.1. Supposing you do not run remove old OCI images with docker/podman image rm, images are cached by OCI runtimes and you can roll back/switch the two system generations just like Grafana was a native Guix System service. And even if you deleted any one of both images, when the Shepherd service starts it tries to pull the image if it's not cached (default docker and podman run behaviour). So as long as your machine is connected to the internet rollbacks are expected to work smoothly.
Lately I've been thinking to implement an oci-fetch fetcher for origin records. This would allow storing OCI images as tarballs in the store. I didn't make much progress on that because I think the guixbuild1-9 users should be granted permissions to run podman or docker commands and I have not investigated how to override their default configuration. Having such fetcher would allow to have rollbacks in all scenarios, even in non internet connected machines.
hope this helps, cheers giacomo
