add HubRegistrationFeatureGates to ClusterManager Spec, and SpokeRegistrationFeatureGates to Klusterlet Spec.

input is like：

  hubRegistrationFeatureGates:
  - V1beta1CSRAPICompatibility=true

  spokeRegistrationFeatureGates:
  - AddonManagement=true
  - V1beta1CSRAPICompatibility=true

And then, registration-operator will convert them to --feature-gates=AddonManagement=true,--feature-gates=V1beta1CSRAPICompatibility=true, add pass to registration deployment

We need to set V1beta1CSRAPICompatibility dynamically to registration controller.

The PR of registration-operator pr 230 on project api, I will modify go.mod and vendor after merging this PR

an example of klustelet CR

Signed-off-by: ivan-cai [email protected]

• Initial commit
• Allows the specification of a ManifestWork.Spec
• Allows Placement targeting of the ManifestWork.Spec
• The controller will take the API Spec details and PlacementDecision and create new ManifestWork resources in the appropriate clusters
• It will also remove ManifestWorks from the appropriate clusters

Signed-off-by: Joshua Packer [email protected]

We have a proposal about how to make ManagedClusterSet exclusive: https://docs.google.com/document/d/1Dl-8g6pJS6wA-MXiaBijDjwXLPX7cJ-HQCoQKIRDze0/edit#, which was discussed in ACM Architecture Topics Open Forum on Sept. 3rd. And it's agreed that option 3 is a better solution. That's the reason why I made this change.

$ kubectl apply --server-side -f manifestwork-example.yaml .... .... I0506 15:03:19.363009 25916 request.go:1097] Request Body: {"apiVersion":"work.open-cluster-management.io/v1","kind":"ManifestWork","metadata":{"creationTimestamp":"2021-04-30T12:18:44Z","labels":{"foo":"bar"},"name":"demo-test","namespace":"zuoxiu-local"},"status":{"conditions":[]}} .... .... I0506 15:03:19.386561 25916 request.go:1097] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Apply failed with 1 conflict: conflict with "work" using work.open-cluster-management.io/v1: .status.conditions","reason":"Conflict","details":{"causes":[{"reason":"FieldManagerConflict","message":"conflict with "work" using work.open-cluster-management.io/v1","field":".status.conditions"}]},"code":409} F0506 15:03:19.387107 25916 helpers.go:115] error: Apply failed with 1 conflict: conflict with "work" using work.open-cluster-management.io/v1: .status.conditions Please review the fields above--they currently have other managers. Here...

b/c the status.conditions field doesnt have the omitempty tag, the server-side applying for manifestwork resources will be constantly failing due to apply conflict. as we can tell from the patch request body, a correct SSA body omitting status subresource should be {"status":{}}, this pull will make SSA work on the manifestwork resources.

The related task: https://github.com/open-cluster-management/backlog/issues/10715

The enhancement proposal: https://github.com/open-cluster-management/enhancements/tree/master/enhancements/sig-architecture/6-placements

Signed-off-by: Yang Le [email protected]

Signed-off-by: Zhiwei Yin [email protected]

issue: https://github.com/open-cluster-management-io/addon-framework/issues/127

1. add work helpers
2. upgrade k8s to v0.24.0 because the the old pkg "github.com/googleapis/gnostic"and the new "github.com/google/gnostic/extensions" conflict

Signed-off-by: Mike Ng [email protected]

Based on the community meeting discussion, this repo was recommended to be a place where some OCM cluster API helper functions can live. I am looking for some feedback before I proceed with enhancing the tests and adding more test cases.

The related feature request: open-cluster-management-io/community#52 Ref: https://github.com/open-cluster-management/backlog/issues/18210

Signed-off-by: haoqing0110 [email protected]

move registration feature gates to api, can be used by registration-operator for check input feature gates if valid.

Signed-off-by: ivan-cai [email protected]

This markdown doc describes updates to the API to align names with existing conventions within ACM and to provide more straightforward language for discussing what has been called the nucleus operator.

Our generated client cannot list the spokecluster due to

Failed to list *v1.SpokeCluster: the server could not find the requested resource (get spokeclusters.cluster.open-cluster-management.io)

this because we register the api with a singular cluster in api group (spokeclusters.cluster.open-cluster-management.io), I think we should use the plural form

The klusterlet CRD generated for kubernetes cluster which's version is <=1.16 is invalid

If we apply this CRD to a 1.16.3 kubernetes cluster, will get:

# kubectl apply -f operator/v1/0001_00_operator.open-cluster-management.io_klusterlets.crd.yaml
The CustomResourceDefinition "klusterlets.operator.open-cluster-management.io" is invalid:
* spec.validation.openAPIV3Schema.properties[spec].properties[registrationConfiguration].properties[featureGates].items.properties[mode].default: Forbidden: must not be set
* spec.validation.openAPIV3Schema.properties[spec].properties[workConfiguration].properties[featureGates].items.properties[mode].default: Forbidden: must not be set

Another validation result from GitHub action

Signed-off-by: zhujian [email protected] Remove the default value of feature gate mode. because if we want to import a managed cluster which Kubernetes version is <= 1.16, it will use v1beta1 CustomResourceDefinition, but the v1beta1 CustomResourceDefinition does not support +kubebuilder:default

~And the default value of the feature gate false is a little confusing. if we configure a feature specifically, In most cases, I think we want our specified feature to be enabled.~

1. syncing a few existing condition types from the addon-framework, including RegistrationApplied and ManifestApplied
2. extending new fields in the addon status to track the validtiy of the certificate