You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When someone uses a Yubikey to for their SSH key or when someone doesn't use ssh-agent, there are currently 4 distinct SSH connections, one in a first step and then 3 in a row:
🚀 ℹ️ [deploy] [INFO] Building profile `system` for node `XX`
warning: Git tree '/home/steven/projects/XX' is dirty
Enter passphrase for key '/home/steven/.ssh/XXXX':
🚀 ℹ️ [deploy] [INFO] Activating profile `system` for node `XX`
🚀 ℹ️ [deploy] [INFO] Creating activation waiter
Enter passphrase for key '/home/steven/.ssh/XXXX':
Enter passphrase for key '/home/steven/.ssh/XXXX':
Enter passphrase for key '/home/steven/.ssh/XXXX':
👀 ℹ️ [wait] [INFO] Waiting for confirmation event...
It might be the case that the latter 3 could be bundled into a single SSH command.
The text was updated successfully, but these errors were encountered:
This is a slightly difficult issue to tackle, the main SSH connections that should exist are:
using Nix to push the profiles to the server
running the activate command, for activating the profile (and ensuring safety with magic-rollback)
running the wait command, for the deployer deploy to know when activation has finished (by watching for the canary file to be created)
running the confirmation command
activate has to be distinct because we let it outlive any other processes so it can roll back if the deployment is not confirmed, and the confirmation command has to be ran on a separate SSH session than wait to make sure we can still initiate not just continue to operate existing SSH sessions.
Pushing has to be distinct for 2 reasons, first because it is simply using nix copy and we have no control over anything executed in that session, second because it is in a separate step, allowing us to push every profile to every server, before starting to activate any of them, so there is less of a delay between subsequent activations.
It should be possible to make activate signal to deploy that activation has completed, thus removing the need for the wait command, but going any further will probably be difficult.
I will also note that if lowering the amount of SSH connections is more important to you than having magic rollback, you can turn it off and there should only be 2 connections instead of 4
When someone uses a Yubikey to for their SSH key or when someone doesn't use ssh-agent, there are currently 4 distinct SSH connections, one in a first step and then 3 in a row:
It might be the case that the latter 3 could be bundled into a single SSH command.
The text was updated successfully, but these errors were encountered: