[bug#71324] news: Add entry for 'docker-service-type' changes.

* etc/news.scm: Add entry.

Change-Id: I98d562d8b435b697b7c6529c5e788b5e2db9fa2a
---
 etc/news.scm | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

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