nixos/nix-daemon: use structural settings

[polykernel]

The nix.* options, apart from options for setting up the
daemon itself, currently provide a lot of setting mappings
for the Nix daemon configuration. The scope of the mapping yields
convience, but the line where an option is considered essential
is blurry. For instance, the extra-sandbox-paths mapping is
provided without its primary consumer, and the corresponding
sandbox-paths option is also not mapped.

This increases the maintenance burden as maintainers have to
closely follow upstream changes which in the case of Nix is made
worse by having to juggle between two state versions, the stable release
and the unstable release, which may include or deprecate features.

One conditional option publicHostKey was added to the buildMachines
submodule corresponding to the newly added base64 encoded public host
key setting exposed in the builder syntax. The build machine generation
was subsequently rewritten to use concatStringsSep to group concatenations.

This commit aims to following the standard outlined in RFC 42[1] to
implement a structural setting pattern. The Nix configuration is encoded
at its core as key-value pairs which maps nicely to attribute sets, making
it feasible to express in the Nix language itself. Some existing options are
kept such as buildMachines and registry which present a simplified interface
to managing the respective settings.

Legacy configurations are mapped to their corresponding options under the
structural settings for backwards compatibility.

Various options settings in other nixos modules and relevant tests have been
updated to use the structural setting for consistency.

The generation and validation of the configration file has been modified to
use writeTextFile instead of runCommand for clarity. Note that validation
is now mandatory as strict checking of options has been pushed down to the
derivation level due to freeformType consuming unmatched options. Furthermore,
validation can not occur when cross-compiling due to current limitations.

[1] - https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md

Motivation for this change

Initial effort for nix-community/home-manager#2324

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/local-flake-based-nix-search-nix-run-and-nix-shell/13433/12

[roberth]

Having a freeformType means that we don't have implicit checking for typos anymore.
Can we check the config file in a derivation using nix.package?
Otherwise this is somewhat of a regression. For some modules this would be an acceptable trade-off, but for such a core element of NixOS it is not.
Perhaps using something like

HOME=..... nix show-config |& sed -e 's/^warning:/error:/' | (! grep unknown\ setting)

[polykernel]

You are right, using freeformType causes typos to remain silent. I think we can incorporate checking into the checkPhase of the derivation which generates nix.conf, but this has the side effects that validation for options specified in the submodule do not occur at the module system level. This essentially means typos and invalid settings are now indistinguishable. This is ok but checking will always have to occur instead of being optional.

An alternate approach is to push the freeformType one level down, so nix.settings becomes a standard submodule, and a descendant typed option like nix.settings.extraConfig is used to for additional settings. This also means merging behavior of the the extra settings and the "main" settings have to be handled manually and outside of the module system.

[polykernel]

I think the first approach(your suggestion) is easier to implement and less error prone, but I am not sure if having the error/warning at the derivation level as opposed to the module system level is acceptable.

[ShamrockLee]

but I am not sure if having the error/warning at the derivation level as opposed to the module system level is acceptable.

I'm still a novice here. IMHO, the modular configurations eventually comes down to the derivation that generates the nix.conf file. As the generation process itself is already outside (or underneath) the modular expressions, the vlidation of the output file nix.conf would not create an extra "non-modulalized" part.

By the way, there are some modules who use the generator attribute provided by type to generate the output file, where the type attribute is specified under the options tree. Maybe the validation could be specified as part of the type or options to go even more "modular". This would probably go through some "consesus-reaching" process such as an additional issue or an RFC, and modules using a rather imperative way of validation would then be modified to fit into the standardized pattern.

[polykernel]

By the way, there are some modules who use the generator attribute provided by type to generate the output file, where the type attribute is specified under the options tree. Maybe the validation could be specified as part of the type or options to go even more "modular".

Could you elaborate on the validation mechanism, I am not sure I understand correctly but do you mean using lib.generators to generate the config which itself and specifying a schema under an option which gets match to its value? The issue when I thought about it is using a schema which is analogous to the mapping all config options in the options tree is it has to be total and essentially match upstream, which increases maintenance burden and is what RFC 42 tries to avoid.

[ShamrockLee]

I cannot recall where I saw them. Maybe I have mixed something up. Sorry for that.

It seems that the generators produce strings instead of files. It then makes more sense to attach the validation through package overriding or similar approaches.

[roberth]

@polykernel

not sure if having the error/warning at the derivation level as opposed to the module system level is acceptable.

While earlier is better, it is still early enough, as derivation builds are also free of side effects.

@ShamrockLee You're thinking of pkgs.formats. Not being in lib, those can produce a derivation. It's also a better name :)

Maybe the validation could be specified as part of the type or options to go even more "modular". This would probably go through some "consesus-reaching" process such as an additional issue or an RFC, and modules using a rather imperative way of validation would then be modified to fit into the standardized pattern.

The separation we have right now, with formats producing a type that returns plain Nix values instead of a derivation, is quite useful because it allows modules to use values from the config. This wouldn't be possible if the type converted the settings to a derivation directly.
I suppose we could use the formats as 'circular programs' though, taking more advantage of laziness. See #144216

[dasJ]

Big 👍 for making the settings consistent with the nix manual and for using a much nicer way of specifying them. However I am not sure if this should go into the 21.11 release or if we should wait for 22.05. In any case we should probably wait for the branch-off and backport to 21.11 if necessary

[ShamrockLee]

It has been a while after the 21.11 branch-off.

Looking forward to its merging!

[thiagokokada]

Is there something blocking this merge?

(Except from the conflicts).

[roberth]

I don't see any blockers and the conflict seems simple.

[polykernel]

I have resolved the conflict and updated the publicHostKey option to be static.

[ShamrockLee]

As the target changelog release note is 21.11, this is to be back-ported to release-21.11. Is that right?

It seems alright as the backward-compatibility is kept with the mapping layer.

[dasJ]

Thanks for pointing this out, I was close to merging this ;)
I don't think we should backport this since it introduces a lot of warnings for existing setups and the large size of this PR leaves room for regressions.
If the release notes are moved to 22.05, I will happily merge this (unless @roberth or anyone else intervenes)

[roberth]

Small things and off-topic things. Looking pretty good otherwise.

[roberth]

There's a bunch of these. Should probably be the default for VM tests. Not a requirement for this PR though.

[roberth]

This would benefit from a second attempt at submodule assertions, #97023 (comment), both in code complexity and error message quality.
(off-topic)