The SSHD port number is not taken into account on the destination pod

[MurzNN]

Describe the bug
I have configured a custom port number in the values.yaml:

sshd:
  service:
    # -- SSHD service port
    port: 2222

But in the destination port I see that it still tries to connect to the default port:

+ rsync -azv '--info=progress2,misc0,flist0' --no-inc-recursive -e 'ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=5' [email protected]:/source// /dest//
ssh: connect to host 1.2.3.4 port 22: Connection refused
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.3]

I think there should be [email protected]:2222, right?

To Reproduce
Steps to reproduce the behavior:

1. Set the custom port number in the values.yaml:

sshd:
  service:
    # -- SSHD service port
    port: 2222

2. Include this yaml to the helm chart: pv-migrate --helm-values ./values.yaml
3. See an error:

❌ Error: migration failed: all strategies failed for this migration

Expected behavior
All should work fine.

Console output

+ rsync -azv '--info=progress2,misc0,flist0' --no-inc-recursive -e 'ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=5' [email protected]:/source// /dest//
ssh: connect to host 1.2.3.4 port 22: Connection refused
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.3]

Version

• Source and destination Kubernetes versions v1.27.8
• Source and destination container runtimes containerd://1.4.4-k3s2
• pv-migrate version and architecture: version 1.7.1 (commit: 1affa11) (build date: 2023-10-09T21:56:55Z)
• Installation method: binary download
• Source and destination PVC type, size and accessModes: ReadWriteMany, 2G, rook-ceph -> ReadWriteMany, 2G, rancher.io/local-path

[utkuozdemir]

It is not well-documented, but the tool does not change any of its behavior based on the passed helm values.

Helm value passing feature is a "use-at-your-own-risk" feature for the users who know what they are doing. So it is quite possible to break the application by overriding the Helm values.

At the moment, sshd.service.port Helm value is only used internally by the local strategy, and there is no way for the user to use a different port.