Naranden writes:

> 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).

Oh, sorry.

> 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".)

Can't speak about this particular error, but I'd had it working.

>>> 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).

That's what running the script of ‘container’ in (info "(guix) Invoking
guix system") gets you, no? No new 'service' should be required.

> 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.)

AFAIU your requirements, they're possible with the shepherd-transient
service and 'guix time-machine' prefixing the command mentioned above.

--

Reply via email to