GNU bug report logs - #71324
[PATCH] services: containerd: Provision separately from docker service.

Previous Next

Full log

Message #35 received at 71324 <at> debbugs.gnu.org (full text, mbox):

From: Oleg Pykhalov <go.wigust <at> gmail.com>
To: Carlo Zancanaro <carlo <at> zancanaro.id.au>
Cc: Julien Lepiller <julien <at> lepiller.eu>,
 "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>,
 71324 <at> debbugs.gnu.org
Subject: Re: [bug#71324] [PATCH] news: Add entry for 'docker-service-type'
 changes.
Date: Tue, 04 Jun 2024 16:41:10 +0300

[Message part 1 (text/plain, inline)]

Hello Carlo,

Thank you for your thoughtful review and valuable suggestions.

Carlo Zancanaro <carlo <at> 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 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.