This is relevant for nixops-compability, as nixops uses these unit files as an indicator for other services that the key is available. It's also helpful to prevent services from starting if the key is not available, e.g. in the case of unexpected (or in general external) reboots.

The definition in nixops uses inotifywait, but a path unit might be the more elegant way to solve this.

In reply to @buckley310:matrix.org
So I'm curious. In my setup my servers all exist inside of my flake outputs.nixosConfigurations, and my outputs.colmena is just a stub that consumes nixosConfigurations and emits a colmena configuration. Is anyone else doing it this way, or just me? I really like the portability of keeping my hosts in nixosConfigurations

Allow flake users to import .#nixosModules.deploymentOptions into their flake, so that the same expression can be used for both, .#colmena.$host as well as .#nixosConfigurations.$host, without the latter complaining about undefined options in "deployment".

Tests seem to pass, building the manual still works and the resulting nixosModules.deploymentOptions works as expected in my configration. What do you think?

(reusing the same attrset for nixosConfigurations and colmena hosts only really works for setups which don't use the name and nodes parameters)

In reply to @buckley310:matrix.org
Yeah I thought about doing that. I had a look at the nix files in colmena and the deployment options aren’t currently exposed, but it looks like they could be