Running migration from OpenEBS to Rook networking requirements, networking setup


I have been trying out HA capabilities with Rook while having OpenEBS first available in a 3 node setup (ubuntu 22.04, k8s_v1.25), having minimumNodeCount: 3 set.

After installing the 1st node and at the end of the installation, joining the 3rd node, the migration should have run and succeeded automatically according to the docs. Instead it failed with the below error:

Error: failed to read current status migration: failed to get migration status: GET http://<hidden>.118:31880/storagemigration/status giving up after 6 attempt(s): Get "http://<hidden>.118:31880/storagemigration/status": dial tcp <hidden>.118:31880: i/o timeout

Allowing inbound communication on all nodes for port 31880 resolved the issue. When I was running the below command manually after allowing port 31880, all pvs were migrated to the rook managed distributed storageClass successfully.

$ /var/lib/kurl/bin/kurl cluster migrate-multinode-storage --ekco-address <hidden>.118:31880 --ekco-auth-token JOIdada<hidden>ewf

    The installer detected both OpenEBS and Rook installations in your cluster. Migration from OpenEBS to Rook
    is possible now, but it requires scaling down applications using OpenEBS volumes, causing downtime. You can
    choose to run the migration later if preferred.
Would you like to continue with the migration now? (y/N) y
2023/12/18 12:53:50 waiting cluster to report as ready for storage migration (10m0s timeout).
2023/12/18 12:53:50 cluster reporting ready for migration: migration ready
2023/12/18 12:53:50 approving cluster storage migration.
2023/12/18 12:53:50 migration has been successfully approved, waiting for it to finish (8h0m0s timeout)...
2023/12/18 12:53:55 cluster reported migration status: "running pvc migration"
2023/12/18 12:55:20 cluster reported migration status: "completed"

I found no mentions of this extra port requirement in the documentations/network-requirements for running the migration from OpenEBS to Rook.
I was wondering how this port gets selected (is it always port:31880?) and allocated to the EKC-operator to handle such requests.

Can you please help me by explaining the above?
If you have a reference to the docs that I have missed and would help in understanding, that would be also very welcome! :slight_smile:

Thanks in advance!

Hi Balint,

That appears to have been an oversight on my part - the migration nodeport will be available on the local node as well at that point, and so we should be able to just hit <nodelocalip>:31880 instead (or service-ip:8080 - both Weave and Flannel allow that).

1 Like

I’ve opened use the internal ekco service address to trigger storage migrations by laverya · Pull Request #5012 · replicatedhq/kURL · GitHub to address this issue.

1 Like

Thank you very much for the quick support and for the fix!

Wishing you a happy new year!