notgne2
commented
10 months ago I would think of this as mildly out of scope (and something that you can solve at the network level with things like Tailscale), but this would help reduce the reasons to disable magic-rollback too. This should make it possible to do things like connect to your machine over IP, alter configuration that changes the IP, and have magic-rollback still able to confirm the deployment (by adding the new hostname or IP to the failover hostnames).
I think it might make more sense to just replace hostname with hostnames (add compat and a deprecation notice), no reason to treat failovers as second class really, we can just have them all in one list and try them in order.
crabdancing
Computer networks are, in the real world, often messy. I've found that a given machine might be connected to ethernet, or to wifi, under a different IP address & hostname. Since wifi is much slower on my network, it's significantly preferable to default to ethernet, and failover to trying to connect over wifi.
Having something like a
--failover-hostnames [HOSTNAMES]option, that would try to connect in a fixed sequence at the pushing step, would make it much easier to script for cases like this (without, e.g., forcing an unnecessary re-evaluation of the entire nix expression each time).Another use case where this would help make deploy-rs more useful: If you want a failover to pushing updates over a reverse SSH tunnel (e.g., the machine is outside of the normal network, but still needs centrally controlled updates).