Value Statement

In practice, we found normally, a managed clusters need to bind with multiple KlusterletConfigs. But currently, it only supports binding with 1 KlusterletConfig via specifying in managed cluster's annotation.

We would like to implement a way to support multiple KlusterletConfigs binding with one managed cluster, in this release we add a default "global" klusterletconfig the managed cluster by default bind to this klusterletconfig without claiming by annotation.

The field in the "global" klusterletconfig priority is lowest. 

Case 1:  Ovrride the global config

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerURL: "example.test.com"
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.demo.com"
 
expected:
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: merged 
spec:
  hubKubeAPIServerURL: "example.test.com"
 
Case 2:  shadow the global config (Empty case)

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerURL: ""
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.demo.com"
 
expected:
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: merged 
spec:
  hubKubeAPIServerURL: ""
 
Case 3:  flow to the global config(Nil case)

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.demo.com"
 
expected:
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: merged 
spec:
  hubKubeAPIServerURL: "example.demo.com"

Definition of Done for Engineering Story Owner (Checklist)

• ...

Development Complete

• The code is complete.
• Functionality is working.
• Any required downstream Docker file changes are made.

Tests Automated

• [ ] Unit/function tests have been automated and incorporated into the
  build.
• [ ] 100% automated unit/function test coverage for new or changed APIs.

Secure Design

• [ ] Security has been assessed and incorporated into your threat model.

Multidisciplinary Teams Readiness

• [ ] Create an informative documentation issue using the [Customer
  Portal_doc_issue template](
  https://github.com/stolostron/backlog/issues/new?assignees=&labels=squad%3Adoc&template=doc_issue.md&title=),
  and ensure doc acceptance criteria is met. Link the development issue to
  the doc issue.
• [ ] Provide input to the QE team, and ensure QE acceptance criteria
  (established between story owner and QE focal) are met.

Support Readiness

• [ ] The must-gather script has been updated.