[feature] add nixos module and library function to generate `deploy.nodes` attributes from its config options

[ppenguin]

I am in the process of transitioning from nixinate to deploy-rs, and found the "duplication" I have to do in the flake a bit awkward.

Background: I have no explicit hosts defined in my flake, but the nixosConfigurations are generated automatically by scanning the hosts/ directory in my flake, which contain all host's system configs in separate sub-directories.

Consequently, it would we nice if one could just do within hosts/somehost/configuration.nix something like

imports = [
   inputs.deploy-rs.nixosModule.default
];

deploy = {
   hostname = "somehost.fqdn.net"
   sshOpts = ...;
   profiles.system = {
      ...
   };
};

and in the flake

deploy.nodes = (deploy-rs.lib.getNodes self.nixosConfigurations) // { /* possibly further "manual" ones */}

where getNodes would just gather the attribute sets for deploy (if they exist) over all hosts in nixosConfigurations

nixinate seems to need _module.args = { nixinate = {}; };, not sure why, maybe because importing the module would lead to recursion? In that case the deploy attribute could be done similarly.

I saw something possibly related in #269 but haven't quite understood how that proposal might be related in terms of UX and functionality.

[PhilTaken]

Hi,

this can be done very well using flake.parts, see my config for example: https://gitea.pherzog.xyz/phil/dotfiles/src/branch/main/modules/flake/deploy.nix

I'd argue this is out of scope for deploy-rs

[ppenguin]

Thanks for the input, I took a quick look. It appears to me that this is just a function that maps some existing nixos configuration options into a function that generates the node deployment expression... I'm doing something a bit similar now. It helps to reduce boiler plate, but it still cannot avoid having node-specific logic outside of the node's system config.

My main point was that deploy-rs deploy options (the ones that cannot be deduced from existing nixos config options) need to be defined in the flake currently, because a nixos-config has no suitable "data attributes" to put them in, even though it's more natural to keep such deploy options with the system config and not separately. I.e. a simple nixos module that declares these options would suffice. I'd argue it is scope of deploy-rs, because it improves UX almost trivially and is specific top deploy-rs.

[PhilTaken]

Personally, I am not a fan of embedding deployment specific data into the nixos configuration for a few reasons but I can see your case.

If you want to draft a simple nixos module we could see how well that integrates with the current deploy-rs.

[ppenguin]

If you want to draft a simple nixos module we could see how well that integrates with the current deploy-rs.

Sure 👌 , I'll "put it on the list", hope to get around to it soon...

[Yethal]

I store all hosts in a separate attrset and generate both nixosConfigurations and deploy.nodes from it via mapAttrs

configurations = mapAttrs (
        key: value:
        nixosSystem rec {
          system = value.system;
          pkgs = import nixpkgs rec {
            inherit system;
            config.allowUnfree = true;
            config.allowUnfreePredicate = (_: true);
            hostPlatform = system;
          };
          specialArgs = {
            inherit inputs;
          };
          modules = value.modules ++ [ { networking.hostName = key; } ];
        }
      ) hosts;