Closed pranavgaikwad closed 4 years ago
@pranavgaikwad do you have more information on this?
Was this a failure on the pod's use of 2222 or was it a failure of running stunnel directly on the support node?
@jwmatthews The failure was on the source side where step 2 was running stunnel on the support node directly as one of the pods was scheduled on the support node. It could be the case that this issue will never be seen in production environments. However, if it does, we currently do not have a good way to solve it. Current implementation requires us to re-build the image with a different port number. The intention behind making port configureable is to make it easier for users to easily change the port themselves instead of us having to re-build the image. The default port still remains as 2222
In my test environment, one of the pods got scheduled on a support node which was already running SSH daemon on port
2222
which made the Stage 3 fail atStart stunnel
step.The port
2222
is hard-coded in the rsync image and at various places in the playbooks. We should find a better alternative to make it easier for users to override the default port.