This commit refactors `services.grafana.provision.datasources` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
This commit refactors `services.grafana.provision.dashboards` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
The current `ExecStart` will not allow for multiple sockets to properly
be passed to the program since the extra newline character is interpreted to
be part of the socket path.
Allow @resources syscalls in the grafana.service unit. While Grafana
itself does not need them, some plugins (incl. first party) crash if
they fail to setrlimit. This was first seen with the official grafana
Clickhouse datasource plugin.
The @resources syscalls set is fairly harmess anyway.
conversions were done using https://github.com/pennae/nix-doc-munge
using (probably) rev f34e145 running
nix-doc-munge nixos/**/*.nix
nix-doc-munge --import nixos/**/*.nix
the tool ensures that only changes that could affect the generated
manual *but don't* are committed, other changes require manual review
and are discarded.
mostly no rendering changes. some lists (like simplelist) don't have an
exact translation to markdown, so we use a comma-separated list of
literals instead.
this mostly means marking options that use markdown already
appropriately and making a few adjustments so they still render
correctly. notable for nftables we have to transform the md links
because the manpage would not render them correctly otherwise.
this notable also now interprets a markdown-flavored list in
triton_sd_config as actual markdown and renders it differently, but this
is arguably for the better (and probably the original intention).
no other rendering changes.
there seems to be a lot of markdown in the prometheus module that
should've been docbook instead. temporarily convert it to docbook to
keep the diff for the docbook->md conversion of prometheus inspectable.
using regular strings works well for docbook because docbook is not as
whitespace-sensitive as markdown. markdown would render all of these as
code blocks when given the chance.
this renders the same in the manpage and a little more clearly in the
html manual. in the manpage there continues to be no distinction from
regular text, the html manual gets code-type markup (which was probably
the intention for most of these uses anyway).
