Message ID | 0ec66ae6dac10ef005782e8a1e9245b57e10d9d4.1717334243.git.go.wigust@gmail.com |
---|---|
State | New |
Headers | show |
Series | [bug#71324] news: Add entry for 'docker-service-type' changes. | expand |
Thank you for the containerd service, Oleg. The main patch’s commit message should contain that you changed doc/guix.texi. It is not clear to me, in the English news, when you write “Moving forward, users are required to specify containerd settings manually for their configurations”, do you really mean that only users *with manual configurations* are required to specify containerd settings *separately*? Could you add this German translation: Oleg Pykhalov <go.wigust@gmail.com> writes: > + (entry (commit "ba9339f59fec1cd49c8d4e9f26834883f5c1aaed") > + (title > + (en "The containerd service is separated from > @code{docker-service-type}") (de "containerd wurde ein eigener Dienst losgelöst von @code{docker-service-type}") > + (ru "Сервис containerd отделен от @code{docker-service-type}")) > + (body > + (en "containerd service has been decoupled from the > +@code{docker-service-type}. Moving forward, users are required to specify > +containerd settings manually for their configurations. > + > +Run @command{info \"(guix) Miscellaneous Services\"} for more info.") (de "Es gibt einen eigenen containerd-Dienst losgelöst von @code{docker-service-type}. In Zukunft müssen Nutzer dort manuelle Einstellungen für containerd vornehmen. Siehe @command{info \"(guix.de) Verschiedene Dienste\"} für genauere Informationen.") > + (ru "Сервис containerd был отделен от @code{docker-service-type}. > +Впредь пользователям потребуется указывать параметры containerd вручную для > +своих конфигураций. > + > +Смотрите @command{info \"(guix) Miscellaneous Services\"} для получения более > +детальных сведений."))) I presume you should direct Russian readers to @command{info \"(guix.ru) Разнообразные службы\"} Regards, Florian
Hello Florian, Thank you for the review. "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes: > The main patch’s commit message should contain that you changed > doc/guix.texi. Ouch, missed it, thank you. > It is not clear to me, in the English news, when you write “Moving > forward, users are required to specify containerd settings manually for > their configurations”, do you really mean that only users *with manual > configurations* are required to specify containerd settings > *separately*? 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. > Could you add this German translation: > > Oleg Pykhalov <go.wigust@gmail.com> writes: >> + (entry (commit "ba9339f59fec1cd49c8d4e9f26834883f5c1aaed") >> + (title >> + (en "The containerd service is separated from >> @code{docker-service-type}") > > (de "containerd wurde ein eigener Dienst losgelöst von > @code{docker-service-type}") > >> + (ru "Сервис containerd отделен от @code{docker-service-type}")) >> + (body >> + (en "containerd service has been decoupled from the >> +@code{docker-service-type}. Moving forward, users are required to specify >> +containerd settings manually for their configurations. >> + >> +Run @command{info \"(guix) Miscellaneous Services\"} for more info.") > > (de "Es gibt einen eigenen containerd-Dienst losgelöst von > @code{docker-service-type}. In Zukunft müssen Nutzer dort manuelle > Einstellungen für containerd vornehmen. > > Siehe @command{info \"(guix.de) Verschiedene Dienste\"} für genauere > Informationen.") Sure. >> + (ru "Сервис containerd был отделен от @code{docker-service-type}. >> +Впредь пользователям потребуется указывать параметры containerd вручную для >> +своих конфигураций. >> + >> +Смотрите @command{info \"(guix) Miscellaneous Services\"} для получения более >> +детальных сведений."))) > > I presume you should direct Russian readers to > @command{info \"(guix.ru) Разнообразные службы\"} Yes, it will be definitely better, thank you. Regards, Oleg.
Hello Oleg, Oleg Pykhalov <go.wigust@gmail.com> writes: > 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. I understand, but only now, that *every* user must make changes. Could you add this sentence to the news *and* to doc/guix.texi? Regards, Florian
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: --8<---------------cut here---------------start------------->8--- (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))))) --8<---------------cut here---------------end--------------->8--- 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). 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. Carlo
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.
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
diff --git a/etc/news.scm b/etc/news.scm index a511b7ffbc..3c11121161 100644 --- a/etc/news.scm +++ b/etc/news.scm @@ -31,6 +31,23 @@ (channel-news (version 0) + (entry (commit "ba9339f59fec1cd49c8d4e9f26834883f5c1aaed") + (title + (en "The containerd service is separated from @code{docker-service-type}") + (ru "Сервис containerd отделен от @code{docker-service-type}")) + (body + (en "containerd service has been decoupled from the +@code{docker-service-type}. Moving forward, users are required to specify +containerd settings manually for their configurations. + +Run @command{info \"(guix) Miscellaneous Services\"} for more info.") + (ru "Сервис containerd был отделен от @code{docker-service-type}. +Впредь пользователям потребуется указывать параметры containerd вручную для +своих конфигураций. + +Смотрите @command{info \"(guix) Miscellaneous Services\"} для получения более +детальных сведений."))) + (entry (commit "8d1d98a3aa3448b9d983e4bd64243a938b96e8ab") (title (en "@command{guix git authenticate} usage simplified")