deploy-rs
deploy-rs copied to clipboard
check if the hostname resolves to localhost and then don't ssh
/cc @balsoft
... so that we can use beloved deploy-rs for all sorts of deployment tasks and ditch all thise brittel scripts around nixos-rebuild
/ nixos-install
/ custom hm deployers
.
https://matrix.to/#/!zRbBgQtZWfualNjvrE:matrix.org/$UHv4_EbQAjyxDC-j04DOqgf-X_5m07w0o7l2A1m4Yzs?via=nixos.org&via=matrix.org&via=wizbos.club
/cc @Pacman99
I'm not sure about this. I feel like it starts to go beyond deploy-rs scope. This tool was built for remote deployments and most of its features are with that in mind.
nixos-rebuild
, nixos-install
, home-manager
are very specifically crafted for local deployments. For example, nixos-rebuild allows for a temporary switch without adding it to your list in the bootloader. home-manager
tool also has some useful tools like checking hm news and listing local packages.
Also the local deployment tools were created by the projects their meant for, nixos/home-manager, so they will be updated to match any changes in how those projects are supposed to be activated.
This tool was built for remote deployments and most of its features are with that in mind.
As far as I'm concerned, local is a special case of remote deployment and I'd surely like to be able to treat it that way.
@Pacman99, you could alternatively view it as a simple optimization in a special case. You could avoid the feature creep and leave it at that.
But I do see your point about how it can lead down a confusing identity crisis for the project, unless it's already decided what it wants to be. A remote only vs all purpose NixOS deployment tool. In any case, deploying locally over ssh really isn't so bad and could be seen as a nice security check (ala the ssh key).
I guess it's all in perspective. What is deploy-rs really good for? ATM that seems to be remote deploys, but could it do a better job at what nixos-rebuild does and become a one stop shop NixOS "activator"?
If so, then maybe it would be worth it to focus in on that and become the nix
for NixOS. But then, maybe deploy-rs doesn't see itself that way? Either way, the project is exceptionally useful for both cases already :smile:
I don't feel like this is out of scope or inappropriate use of the project at all, in fact I don't think I have used nixos-rebuild
in a very long time and use this for all of my local deployments, I also wouldn't even mind replicating the functionality to allow temporary activating/switching too. deploy-rs is for deploying, local or remote, and should have all the functionality and optimizations which make sense for a deploy tool of either type.
I would probably be ok with this as described, but if I had to pick a problem it would be with making an assumption based on hostname, maybe having a different property would be semantically nicer?
I would probably be ok with this as described, but if I had to pick a problem it would be with making an assumption based on hostname, maybe having a different property would be semantically nicer?
This is an important point: kuma.example.com
and kuma.example.net
can be two different hosts who share the hostname.
I would be more than happy if we could switch to an underlying fqdn
semantic.
After thinking about it, I'm against checking for hostnames/fqdns as a way to tell if the deployment is "local", and would instead prefer a simple CLI flag (like --local
) to start out.
I would want a propety in the flake as well as a CLI flag, when I update my machine I like to run just deploy /etc/nixos
, deploy --local /etc/nixos
doesn't have quite the same charm to it.
Though I think it might not always be useful as it's totally reasonable to deploy to the same node from multiple different hosts, including both local and remote hosts, and in those cases you would have to use the CLI flag (or be ad-hoc editing your deployment details each time). For this it would be nice to have logic in Nix rather than deploy-rs reason if it is local or not, but that is an impurity, maybe it's possible to introduce this somehow without having to run it with --impure
, though I imagine not.
Another option is resolving the host, checking if the IP is 127/8
seems somewhat better than checking if the hostname is localhost
.
deploy-rs
' features over nixos-rebuild
that I would be interested in having locally are mostly the auto-rollback features, which I think are cool enough that it deserves being the de-facto standard for deploying NixOS configurations. I don't see the value in replicating this in the existing deploy scripts, be it home-manager
or nixos-rebuild
.
The other nice benefits, that deploy-rs
reads flake attributes and knows to --use-remote-sudo
without CLI flags could feasibly just be added to nixos-rebuild
instead.