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

Previous Next

Package: guix-patches;

Reported by: Oleg Pykhalov <go.wigust <at> gmail.com>

Date: Sun, 2 Jun 2024 13:06:02 UTC

Severity: normal

Tags: patch

Done: Oleg Pykhalov <go.wigust <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Carlo Zancanaro <carlo <at> zancanaro.id.au>
To: Oleg Pykhalov <go.wigust <at> gmail.com>
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: Wed, 05 Jun 2024 00:22:09 +1000
HI Oleg,

On Tue, Jun 04 2024, Oleg Pykhalov wrote:
> 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.

Ah, okay. That complicates things if we want to support multiple
options. I misunderstood the situation.

> Will this mechanism support the use of different container runtimes?

No, unfortunately I don't think it would. The extensions are a static
property of the service type, so the request to create a containerd
service can't be turned on/off based on the configuration. You could
make the containerd configuration have a "do nothing" configuration by
default, but then that's confusing for using containerd directly.

To manage multiple container runtimes we could add additional docker
service types, with names like containerd-docker-service-type. That
might be a pain to maintain, depending on how many container runtimes
there are.

I have thought for a while now that would be nice to have a way for a
service extension to return a "disregard this extension" value. This
would allow us to have extensions that are turned on/off by config.
Unfortunately, it doesn't seem straightforward to do given the way
things are currently implemented.

> 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.

I can't think of a way to warn the user if they haven't provided a
containerd service, but to create one anyway. The only way I could think
to do it would be to force them to provide an explicit configuration, so
we can detect that the service was not created with the default
configuration (i.e. by the docker service). That's not ideal.

Carlo




This bug report was last modified 291 days ago.

Previous Next


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