Update.

Signed-off-by: xuezhaojun <[email protected]>

enhancements/sig-architecture/100-relocatable-klusterlet/README.md

@@ -14,7 +14,7 @@ This proposal aims to enhance the Klusterlet API to enable agents to smoothly sw
 ## Motivation
 Currently, an agent can only point to one hub, requiring manual configuration and operations to switch agents to another hub.
 
-To address this, we propose extending the `Klusterlet` API to include multiple bootstrap-kubeconfigs from different hubs. We will provide a mechanism for agents to determine when they should switch to another hub. This mechanism will enable agents to complete the switching process automatically, eliminating the need for manual operations.
+To address this, we will provide a mechanism for agents to determine when they should switch to another hub. This mechanism will enable agents to complete the switching process automatically, eliminating the need for manual operations.
 
 This mechanism will be beneficial for various scenarios, including upgrading, disaster recovery, improving availability, etc.
 
@@ -45,63 +45,29 @@ N/A
 
 ## Design Details
 
-### API Changes
-
-Klusteret changes:(No explicit changes, update a potential dependency)
-```golang
-// Klusterlet represents controllers to install the resources for a managed cluster.
-// When configured, the Klusterlet requires a secret named bootstrap-hub-kubeconfig in the
-// agent namespace, or a secret named bootstrap-hub-kubeconfigs to allow API requests to
-// the hub for the registration protocol.
-//
-// The 'bootstrap-hub-kubeconfigs' contains the bootstrap-kubeconfig for multiple hubs,
-// with the hub's name as the key and the corresponding kubeconfig as the value.
-// Note: While you should not use the hub's name as the sole identifier for hubs in your code,
-// it is included for the purpose of enhancing readability in log files.
-// The Klusterlet calculates a preferred kubeconfig of hubs and use it in the bootstrap registration process.
-//
-// In Hosted mode, the Klusterlet requires an additional secret named external-managed-kubeconfig
-// in the agent namespace to allow API requests to the managed cluster for resources installation.
-type Klusterlet struct {
-```
-
-ClusterManager changes:
-```go
-type RegistrationHubConfiguration struct {
-	...
-	// cleanUpNotChosenHub represents whether to clean up the managed cluster resources if the agent doesn't choose this hub.
-	// +optional
-	// +kubebuilder:default=true
-	CleanUpNotChosenHub bool `json:"cleanUpNotChosenHub,omitempty"`
-}
-```
-
 ### Workflow
 
 Let’s seen an example, assume we have 2 hubs: hub1 and hub2, and we want to registry cluster1 first to hub1 then switch to hub2.
 
-First, we create a configmap `chosenManagedClusters` in the `open-cluster-management` namespace of each hub, on hub1, it should contains  `cluster1` as key to represent hub1 now is the perferred hub of cluster1.
+First, we create a managedcluster CR with a specific label `operator.open-cluster-management.io/chosen` on each hub, on hub1, it represents whether hub is chosen for this managed cluster. On hub1:
 
 ```yaml
-kind: ConfigMap
-apiVersion: v1
+apiVersion: cluster.open-cluster-management.io/v1
+kind: ManagedCluster
 metadata:
-  name: chosenManagedClusters
-  namespace: open-cluster-management
-data:
-  cluster1: ''
-  # The configmap can contains multiple keys representing different managed clusters, for example:
-  # cluster2: ''
-  # cluster3: ''
+  name: cluster1
+  labels:
+    operator.open-cluster-management.io/chosen: "true"
 ```
 
-However, the configmap on hub2 is empty, indicating that it is not the leader hub of any managed cluster.
+On hub2, the value of the label on hub2 is `false`, indicating that it is not chosen by cluster1.
 ```yaml
-kind: ConfigMap
-apiVersion: v1
+apiVersion: cluster.open-cluster-management.io/v1
+kind: ManagedCluster
 metadata:
-  name: chosenManagedClusters
-  namespace: open-cluster-management
+  name: cluster1
+  labels:
+    operator.open-cluster-management.io/chosen: "false"
 ```
 
 Next, we follow the regular registration process and deploy the klusterlet manifest. However, this time we need to store the kubeconfigs of both hubs as secrets in the `open-cluster-management-agent` namespace. The required lable is `config.open-cluster-management.io/bootstrap-kubeconfig-candidate-of-hub`.
@@ -131,15 +97,12 @@ data:
   kubeconfig: YXBpVmVyc2lvbjogdjEK...
 ```
 
-At the start of the registration process, the klusterlet will use candidate bootstrapkubeconfigs to retrieve the configmap `chosenManagedClusters` on each hub. If a hub meets the following three conditions, it will be designated as a preferred candidate for the agent:
+At the start of the registration process, the klusterlet will use candidate bootstrapkubeconfigs to retrieve the managed cluster `cluster1` on each hub. If the `operator.open-cluster-management.io/chosen` equals to `true`, it will be designated as a preferred candidate for the agent:
 
 1. The hub is connectible.
-2. The configmap `chosenManagedClusters` exists.
-3. The key corresponding to the name of the managed cluster exists.
+2. The label `operator.open-cluster-management.io/chosen` equals to `true`.
 
 The agent will start registry when there is only 1 preferred candidate, the whole status transition diagram is like the following:
 [![status transition diagram](./status-transition-diagram.png)](./status-transition-diagram.png)
 
-Next, we need to change the `chosenManagedClusters` configmaps on hub1 and hub2 to trigger the switch. The klusterlet will replace the bootstrapkubeconfig it is using to register to hub2.
-
-Additionally, it will attach an annotation `operator.open-cluster-management.io/not-chosen-hub` to the managed cluster `cluster1` on hub1. The user can choose to automatically remove it or keep it by configuring the `clustermanager.spec.registrationConfiguration.cleanUpNotChosenHub`.
+Next, we need to change the `operator.open-cluster-management.io/chosen` label on hub1 and hub2 to trigger the switch. The klusterlet will replace the bootstrapkubeconfig it is using to register to hub2.