From: Oleg Pykhalov <go.wigust@gmail.com>
To: Carlo Zancanaro <carlo@zancanaro.id.au>
Cc: Julien Lepiller <julien@lepiller.eu>,
"pelzflorian \(Florian Pelz\)" <pelzflorian@pelzflorian.de>,
71324@debbugs.gnu.org
Subject: [bug#71324] [PATCH] news: Add entry for 'docker-service-type' changes.
Date: Tue, 04 Jun 2024 16:41:10 +0300 [thread overview]
Message-ID: <87zfs0g70p.fsf@gmail.com> (raw)
In-Reply-To: <87zfs13qth.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Tue, 04 Jun 2024 21:11:54 +1000")
[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
next prev parent reply other threads:[~2024-06-04 13:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-02 13:04 [bug#71324] [PATCH] services: containerd: Provision separately from docker service Oleg Pykhalov
2024-06-02 13:15 ` Oleg Pykhalov
2024-06-02 13:17 ` [bug#71324] [PATCH] news: Add entry for 'docker-service-type' changes Oleg Pykhalov
2024-06-03 9:30 ` pelzflorian (Florian Pelz)
2024-06-03 14:47 ` Oleg Pykhalov
2024-06-03 15:17 ` pelzflorian (Florian Pelz)
2024-06-03 22:30 ` [bug#71324] [PATCH 1/2] services: containerd: Provision separately from docker service Oleg Pykhalov
2024-06-03 22:30 ` [bug#71324] [PATCH 2/2] news: Add entry for 'docker-service-type' changes Oleg Pykhalov
2024-06-04 10:13 ` pelzflorian (Florian Pelz)
2024-06-04 11:11 ` [bug#71324] [PATCH] " Carlo Zancanaro
2024-06-04 13:41 ` Oleg Pykhalov [this message]
2024-06-04 14:22 ` Carlo Zancanaro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zfs0g70p.fsf@gmail.com \
--to=go.wigust@gmail.com \
--cc=71324@debbugs.gnu.org \
--cc=carlo@zancanaro.id.au \
--cc=julien@lepiller.eu \
--cc=pelzflorian@pelzflorian.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).