[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#71324] [PATCH] news: Add entry for 'docker-service-type' changes.
From: |
Oleg Pykhalov |
Subject: |
[bug#71324] [PATCH] news: Add entry for 'docker-service-type' changes. |
Date: |
Tue, 04 Jun 2024 16:41:10 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hello Carlo,
Thank you for your thoughtful review and valuable suggestions.
Carlo Zancanaro <carlo@zancanaro.id.au> writes:
> On Mon, Jun 03 2024, Oleg Pykhalov wrote:
>> Every docker-service-type user will need to add containerd-service-type
>> to their system configurations, otherwise a message about not any
>> service provides containerd will be displayed during reconfigure.
>
> Is this necessary? If I understand correctly, the docker service has a
> hard dependency on containerd, so having to specify it every time is
> unnecessary boilerplate. Could we add an extension for containerd that
> does nothing, but which the docker service can use just to request its
> inclusion? Something like:
Technically, Docker relies on a container runtime, not specifically
limited to containerd. While containerd is a popular choice, there are
alternative runtime options available as well.
> (define containerd-service-type
> (service-type (name 'containerd)
> (description ...)
> (extensions ...)
> ;; Declare an extension point, so containerd can be requested
> ;; by other services without affecting its configuration.
> (compose (const #t))
> (extend (lambda (config _) config))
> (default-value (containerd-configuration))))
>
> (define docker-service-type
> (service-type ...
> (extensions
> ...
> (service-extension containerd-service-type (const #t)))))
>
> That way users could instantiate containerd themselves if they need some
> particular configuration, but if not it would be pulled in automatically
> by the docker service. Hopefully this would cause less of an issue for
> existing configs that don't use a custom containerd (like mine).
Will this mechanism support the use of different container runtimes?
> We could even, for backwards compatibility, allow the docker service
> type to pass through the containerd package from its old configuration
> (while printing a warning). This could make it possible to separate
> containerd from docker without breaking any existing configurations.
If I understand correctly, could we potentially prevent users from
needing to provide the containerd-service-type and instead issue a
warning that they will need to provide it in the future? I believe this
would be a great solution, but I couldn't locate it while writing this
patch.
Regards,
Oleg.
signature.asc
Description: PGP signature