Deprecate clusterctl backup and clusterctl restore

[fabriziopandini]

Detailed Description

clusterctl backup and clusterctl restore command names are misleading and they drive a lot of confusion in the users.

Those command does not provide a full backup and restore solution, they never intended to be.
Instead they allow to break down the cluster move command workflow into two parts; clusterctl backup is the first part where move reads from the source cluster, clusterctl restore is the second part where move writes to the target cluster.

In order to avoid further confusion I suggest to:

• deprecate clusterctl backup and offer the same functionality by cluster move --to-folder, where --to-folder is a new flag that is mutually exclusive of the existing to-kubeconfig
• deprecate clusterctl restore and offer the same functionality by cluster move --from-folder, where --from-folder is a new flag that is mutually exclusive of the existing kubeconfig

/kind api-change
/kind cleanup

[oscr]

Is this a "help wanted" issue? If so, I would love to take it when I get back from the fells next week.

[fabriziopandini]

/help-wanted

@oscr, feel free to assign yourself to this task

[oscr]

/assign

[mmmmmmpc]

Please don't do this.
A cluster backup and restore tool abd procedure is needed in case the management cluster suffers any incidence.
Extending this to include the resources needed to fully save a management cluster and restore it would have a very positive impact in users.

[oscr]

@mmmmmmpc Could you please explain a little more? No functionality is being removed. It's just changed name and location: backup -> move --to-directory and restore -> move --from-directory.

[fabriziopandini]

And this change is meant to avoid confusion

Those command does not provide a full backup and restore solution, they never intended to be.

backup and restore should be executed using tools like velero or by leveraging GitOps tools capable to consider everything there is in a Cluster, not only CAPI resources in a namespace

[kfox1111]

Fair. But does this mean the backup commands are successful in backing up/restoring all the bits the cluster api is in charge of?

IE, say you have a management cluster, as per recommended best practice. Is dumping the objects via backup, and saving them enough to be able to reinstall the management cluster and have it re-manage the managed cluster?

IE, this backup on mgmt cluster, and velero on managed cluster?

[mmmmmmpc]

@fabriziopandini ... the Management Cluster is not a cluster to handle any workload but a very special case.
It handles all the deployment and changes to the productive clusters (i.e. worload clusters and shared services clusters).
Velero is intended to work to restore the productive clusters ... while clusterctl can take care of integrating them into a running management cluster.
If you see it from this perspective, the restore of a management cluster, in case it gets corrupted or destroyed, is not acommon task related to productive workloads but a task related to rebuilding the management infrastructure, which in this case is hte management cluster.
Having clusterctl is the place for that (which for example, takes care of moving prodductive clusters from one management cluster o another ... and no one would say, "do that with velero"), and having the backup option for it was a very nice first step.
If kept as it is, we all have the chance to collaborate in adding what is needed to clusterctl so that it can backup and restore the special case that is a management cluster.

My 0.02 €

[oscr]

This sounds like a much larger discussion than the scope of this specific issue. Maybe we could start a discussion / office hours / take it on slack to get more people involved?