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
Describe the bug
Start a mixed cluster copy using "local" strategy, pods pop fine but copy is stuck at 0%.
Logs in source pod show the following error:
Additional context ⚠️ The major thing to add to reproduce is using an SSH agent and/or multiple keys configured in ~/.ssh/config, which is my case.
Daily, I use different SSH keys for different group of server, as well as agents (declared using SSH_AUTH_SOCK env var).
At the time of the failing tests, I had a running agent with 2 keys loaded, which were probably offered first to the source pod, which refused them as they were unknown.
Unsetting the SSH_AUTH_SOCK env variable allowed the copy to run smoothly.
To fix the issue, I think their could be 2 approaches:
ignore existing SSH agents and keys to prevent client from using them when starting connections
use the keys and agent when available
Last but not least, this tool is great, thanks a lot ! 👏
The text was updated successfully, but these errors were encountered:
Describe the bug
Start a mixed cluster copy using "local" strategy, pods pop fine but copy is stuck at 0%.
Logs in source pod show the following error:
To Reproduce
Steps to reproduce the behavior:
pv-migrate --compress --source=data-wordpress-mariadb-0 --dest=data-wordpress-mariadb-0 --source-context=xxx-old --dest-context=xxx-new --source-namespace=migration-test --dest-namespace=migration-test --ignore-mounted --strategies=local
Expected behavior
Copy should go through.
Console output
Not relevant.
Version
Not relevant.
Additional context
⚠️ The major thing to add to reproduce is using an SSH agent and/or multiple keys configured in ~/.ssh/config, which is my case.
Daily, I use different SSH keys for different group of server, as well as agents (declared using SSH_AUTH_SOCK env var).
At the time of the failing tests, I had a running agent with 2 keys loaded, which were probably offered first to the source pod, which refused them as they were unknown.
Unsetting the SSH_AUTH_SOCK env variable allowed the copy to run smoothly.
To fix the issue, I think their could be 2 approaches:
Last but not least, this tool is great, thanks a lot ! 👏
The text was updated successfully, but these errors were encountered: