volsync icon indicating copy to clipboard operation
volsync copied to clipboard

volsync migration: support for cluster to cluster migration

Open vh05 opened this issue 2 years ago • 2 comments

Describe the feature you'd like to have.

Users look to migrate from one k8s cluster to other because of many reasons. ex: ocs(glusterfs) to odf (cephfs). Volsync migration utility can be extended to provision such feature.

What is the value to the end user? (why is it a priority?)

Migration across clusters is much needed ask and users tend to move from one cluster to other (cloud to cloud as well)

@JohnStrunk Please review the feature

vh05 avatar Mar 02 '22 05:03 vh05

I think this is handled by the cli's replication set of sub-commands. Something like:

$ kubectl volsync replication create ...
$ kubectl volsync replication set-source --copymethod Direct ... # source is the PVC in the old cluster
$ kubectl volsync replication set-destination --copymethod Direct --storageclass newsc ... # destination is the new cluster
$ kubectl volsync replication sync  # actually transfer the data
$ kubectl volsync replication delete  # clean up

Is there more that you believe we should be doing?

JohnStrunk avatar Mar 02 '22 13:03 JohnStrunk

$ kubectl volsync replication set-source --copymethod Direct ... # source is the PVC in the old cluster $ kubectl volsync replication set-destination --copymethod Direct --storageclass newsc ... # destination is the new cluster

I was thinking to bring this while filing this issue.

What I think is, the above mentioned commands set-source and set-destination should also be part of migration with default --copymethod Direct (or else (I prefer) the functionality of set-source and set-destination can be assumed internally as part of migration create command and exclude set-source and set-destination sub commands). If migration subcommand can have this, then the user will be more sure what the command is doing and refers migration subcommand for any of the migration operation.

I understand the replication subcommand serves the same purpose but doing it as part of migration subcommand does make more sense.

Please correct me if wrong.

vh05 avatar Mar 02 '22 14:03 vh05

Given that this can be handled by replication, I don't want to duplicate.

JohnStrunk avatar Jan 04 '23 15:01 JohnStrunk