[bug#68757] [PATCH] services: dns: Add unbound service

["Sören Tempel" <soeren@soeren-tempel.net>]

Ludovic Courtès <ludo@gnu.org> wrote:
> Hi Sören,

Hi Ludovic,

> For ‘remote-control’ and ‘server’, it’s not clear to me why we resort to
> alists instead of records (or fields within this record type); it looks
> inconsistent.
> 
> Could you consider turning them into records or fields?

Prior to submitting this patch I was experimenting with both records and
alists for the Unbound configuration abstraction. Unbound has **a lot**
of configuration options and new options are constantly getting added by
upstream, see unbound.conf(5). Therefore, supporting them through a
record type with fields for each configuration option requires a lot of
code. Furthermore, it will require constant maintenance to keep up with
new upstream options.

I looked at prior art and noticed that the Nix service configuration for
unbound just uses a plain hash with string keys [1]. This seemed like a
good way to deal with the complexity of unbound.conf, hence I opted for
a similar approach here. I don't think it's feasible to model the
configuration using a record type with several hundred fields and, as rde
uses an alist-based approach for services with similar complexity, I
don't think its unheard of in the Guix world either. While it is not as
“type safe” as a record-based approach (e.g. you can create semantically
invalid unbound configurations), it offers good forwards compatibility
and requires less Scheme code.

In theory, it would be possible to model sections with less options
(e.g. the ‘remote-control’ or ‘server’ option) using records. However,
using alists for some sections and records for others seems inconsistent
to me.

Please let me know what you think so I can revise this accordingly.

> I recommend adding an “escape hatch” by which users may provide raw
> strings (or a file-like object) that gets inserted into the config file.

I think at the moment, it should be possible to express all possible
unbound configurations using the alist-based approach. If not, I would
consider it this a bug in the Scheme abstraction. As such, I don't think
there is a need for an “escape hatch” right now (see also: my comment on
records and forwards compatibility above). However, if this is a common
idiom then I can add such an escape hatch.

The other things you mentioned seem obvious to me and I will just
implement them as suggested in a v2 revision of the patch. Thanks for
the feedback!

Greetings,
Sören

[1]: https://github.com/NixOS/nixpkgs/blob/0a37316d6cfea44280f4470b6867a711a24606bd/nixos/modules/services/networking/unbound.nix#L102-L126