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.