nixos/stalwart: add module-specific stateVersion, clean up and switch logging from stdout to journal

[axelkar]

Sorry for a PR with multiple changes... Title basically says it.

journald's centralized logging has many advantages:

• External centralized logging can simply source from journald
• journald's auto-vacuum options (e.g. SystemMaxUse) can make sure logs don't take up too much space
• Logs are in a single timeline, which is useful for analysis

This is also the first module-specific stateVersion in Nixpkgs. It has been planned before (ping @infinisil @KFearsoff). Basically it makes migrating easier/possible and also makes possible using newer state versions with an old system.stateVersion. The stateVersion doesn't have defaults (not just set to follow config.system.stateVersion by the module) so the user explicitly sets it to the version they first installed Stalwart on or the current NixOS version for new installs.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[axelkar]

Module maintainer ping:
@happysalada
@pacien
@jonnynightingale
@norpl

[happysalada]

This looks good, leaving this open to give others a chance to review

[axelkar]

I'd like to include an example like "the current NixOS version" in this error message.

nixpkgs/lib/modules.nix

Line 1212 in dfcc8a7

"The option `${showOption loc}' was accessed but has no value defined. Try setting the option.";

[happysalada]

I dont have any qualms with this PR. I'm just noticing this would be breaking for existing users if they dont have the state version set. So if we merge this, we should do this earlier Rather than before we enter the freeze period for 26.05

[axelkar]

I'd like to include an example like "the current NixOS version" in this error message.

This would require changing option value merging; not viable for this PR.

[amaanq]

I'm not sure why the stalwart module has its own stateVersion, no other module does this and it is very bizarre to have users set this manually. I ran into this and was quite lost, especially so seeing that this is the only module to have this.

Users shouldn't be changing their stateVersion at all, and the module should track the system one instead. Updating the stateVersion can be done manually but typically the user needs to be very careful & thorough in ensuring that nothing breaks once they do so (e.g. they've performed any necessary db migrations).

Frankly I think 75742d2 should be reverted or reworked.

[axelkar]

Thank you for the feedback. I agree that users shouldn't be updating their stateVersion, and this PR addresses exactly that by providing Stalwart with its own independent state version option so that it can be enabled on its own, separately from NixOS's state version. For example, one of my servers has the NixOS state version set to 24.05, but I'd want to use the latest Stalwart storage format without having to manually disable the 24.05 configuration applied by the module. The changes here begin a pattern where individual modules can have their own state versions, which provides NixOS users (and possibly users of other OSs with modular services) with more flexibility.

An easy change we could do to possibly improve UX would be to make this opt-in and have the option default to system.stateVersion. It'd still be discoverable even if it didn't have the error. It's important enough to be in the release notes but maybe it indeed should be opt-in?

[happysalada]

@amaanq yes there is no prior example of this, but what is the fundamental problem with having this ? What do you propose instead ?

This is is just versioning the module in the end. The fact that there is no default is painful, but I dont see how this can be avoided.

[rhendric]

If you haven't seen it, I'm campaigning for a different per-module stateVersion pattern as introduced here. Since as of this PR, it seems you don't depend at all on system.stateVersion, there's no actual conflict between the two patterns — I'm only going to try to migrate modules that use system.stateVersion. But since you're talking about how no other modules do this and considering using system.stateVersion to produce a default here, you might want to keep an eye on this.