Allow Cluster API to stop controlling my workload cluster

[iming0319]

User Story
As an operator of a management cluster, given that I have a management cluster that I have used to deploy several workload clusters, I want to remove the Cluster/Machine objects representing one workload cluster from my management cluster without deprovisioning workload cluster.

As an operator of a management cluster, given that I have a management cluster that I have used to deploy several workload clusters, I want to uninstall Cluster API from my management cluster without deprovisioning my workload clusters.

As an operator of a management cluster, given that I have a management cluster, I want to use it to manage workload clusters that were created by a different management cluster.

Detailed Description
I just want to get rid of cluster api from controlling my workload cluster

Anything else you would like to add:

What can I do?
Just delete the related name spaces in management cluster?
Or the clusterctl delete provider command can satisfy me?

/kind feature

[k8s-ci-robot]

@iming0319: This issue is currently awaiting triage.

If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fabriziopandini]

If I got right the three use cases, IMO they are kind of different/unrelated, so my suggestion is to scope down the issue or break it down into multiple issues in order to keep the discussion focused and make the issue actionable.

Some additional context about my opinion above:

• The first use case seems to match what is written in the detailed description, which is to allow Cluster API to stop controlling my workload cluster. I think it can be achieved as of today by pausing the cluster and then deleting all the objects in the cluster, which requires a deep understanding of our API; however, before exploring if/how to improve this it will be interesting to understand how many users are interested in this use case.

• The second use case, uninstall CAPI leaving orphaned clusters, IMO it is already supported even if not intentionally (this is what happens w.g. when I nuke my dev management clusters without deleting workload clusters).

• The third use case, manage a workload cluster created by another management cluster, is something in between "move a single cluster" (which was a use case that never got traction, see Re-define the scope of clusterctl move #3354) and adopt existing clusters, which is being discussed with slightly different angles in Cluster-api takeover of existing Kubeadm clusters #7776 and Adopt existing clusters on vSphere #7573. This IMO requires its own discussion or, even better, to be merged in one of the above threads

[fabriziopandini]

Adding
/triage needs-information
While we scope down the issue

[enxebre]

I read the user stories above as function requirements, to get more context can we elaborate the use cases motivating these functional requirements? e.g In an non recoverable disaster scenario for my management cluster I'd like my workload cluster to keep operating with no down time...

I'd expect all/most of these requirements to be possible by leveraging .Pause API input.

[fabriziopandini]

/close
Due to lack of follow up
If necessary, let's try to re-open more focused issues based on concrete use cases as suggested above

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to this:

/close
Due to lack of follow up
If necessary, let's try to re-open more focused issues based on concrete use cases as suggested above

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.