On 5/16/25 04:14, James Thomas wrote: > Naranden writes: >> On 5/11/25 00:03, Naranden wrote: >>> I am wondering about writing various >>> container operating-system definitions, adding those as services to a >>> host operating-system definition, and then using guix deploy to deploy >>> the host operating-system. >> >> In case anyone is interested, I was able to get something *like* this to >> work with Docker containers: I can define an operating-system that is >> then included as a service in a parent operating-system. > > FYI: rootless-podman might be better.
I agree, but the integrated OCI service that accepts an operating-system definition (through oci-image) does not (yet) support Podman (the <https://issues.guix.gnu.org/76081> "OCI provisioning service" patches may change that). Also the basic rootless Podman service is not working. (Running `podman` as root: "Failed to obtain podman configuration: runroot must be set". As user: "Failed to obtain podman configuration: mkdir /run/user/0/libpod: permission denied".) >> With Docker involved here, there is extra time and disk space used >> bundling and extracting the OCI image. Guix bundles the operating-system >> into an image.tar.gz and then the parent operating-system tells Docker >> to load that image from the store. >> >> I suppose there must be some way to make this work like Guix system >> containers, where everything the container needs is loaded from the >> store rather than through Docker. > > Why not build the 'container' script for the users and let them run it? I'm not sure what you mean. The goal isn't to ship to other users but to declare a specific, reproducible operating-system with services that can be deployed on a local (real) system, in a VM, or remotely. More specifically, the goal is to include a guix system container service in an operating-system definition--in other words, a Guix operating-system (container) nested in another operating-system (parent). I was able to make that work that with Docker as described in my previous message. Making it work with Podman would be better. But in both cases, many of the advantages of using Guix end at the point of producing the OCI image (because it is essentially an export from Guix). Making it work with Guix with be a lot better--all the Guix machinery would work end-to-end. There are three other related questions that might be good to include here as further explanation: 1. I can bundle a package (and its dependencies) and run a command in a container with `guix shell --container $package -- run`. Can I set up the same thing to happen as a Shepherd-managed service (in an operating-system definition)? 2. And if that can be done, can I set the channels and use package inferiors so I would get the equivalent of `guix time-machine -C $channels -- shell ...` but in a Shepherd-managed service as in (1)? 3. And if *that* can be done, can I do the same with an entire nested operating-system as in my original question and example?! That is, equivalent to `guix time-machine -C $channels -- system vm $file` but as a Shepherd-managed service nested inside a parent operating-system definition, where the parent operating-system definition could itself be executed in a VM with `guix time-machine -C $channels -- system vm $file`. (It's amazing that this level of reproducibility might actually be possible with Guix.) I appreciate the feedback. Thanks, Naranden
