[bug#66160] [PATCH] gnu: Add oci-container-service-type.

[paul]

Hi Ludo’ ,

thank you for your explanation.

On 10/24/23 17:41, Ludovic Courtès wrote:
> If you take the route of one ‘oci-container-service-type’ per
> daemon/server that you want to run,
what you mention below is already implemented in my latest patch [0]:
> then <oci-container-configuration>
> should probably have a ‘user’ field to specify under which user to run
> the container.
this is oci-container-configuration-user
> <oci-container-configuration> would need
> a ‘provision’ field to specify the Shepherd service name (the
> “provisions”).
this is oci-container-configuration-name. I now realize that "name" it's 
not the best field name, so I'm sending a patch with this renamed to 
oci-container-configuration-provision .
>   Likewise, perhaps a field to specify the data directory
> is needed.
I don't think oci-container-configuration should concern about a data 
directory since oci containers themselves only have a volume concept 
which is covered. what you brought into my mind is that docker supports 
-w/--workdir so I implemented it and added it to the patch I'm about to 
send.
> Does that make sense?

Yes, thank you :) My doubts come from shepherd-root-service-type 
accepting a list of services. What would be the reason to break 
consistency with it? I think we would add the friction of having to write


(service nextcloud-cron-oci-service-type)

(service nextcloud-oci-service-type)


instead of simply


(service nextcloud-cron-oci-service-type)


One way out of this if you think is a good solution could be having an 
oci-containers-service-type that's supposed to be only extended whose 
value would be a list of <oci-container-configuration> and an 
oci-single-service-type that could not be extended whose value would be 
a single <oci-container-configuration> . The oci-single-service-type 
would simply extend the oci-containers-service-type and maintenance 
would be free.

What do you think?


Thank you for your help,

giacomo


[0]: https://issues.guix.gnu.org/66160#10-lineno69