[APIP] Update Operator helm-chart#2749
Draft
DDH13 wants to merge 11 commits into
Draft
Conversation
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
- Introduced CustomResourceDefinitions for SubscriptionPlan and Subscription, enabling management of subscription plans and subscriptions within the WSO2 API Gateway. - Implemented a conversion webhook for the CRDs, allowing for seamless versioning and updates. - Enhanced the operator deployment to support webhook functionality, including dynamic port configuration and certificate management. - Added a service for the webhook to facilitate communication between the operator and the Kubernetes API. - Updated Helm chart values to include configuration options for enabling/disabling the webhook and setting certificate validity.
The v1alpha1/v1 schemas are field-identical today (see api/v1alpha1/conversion.go), and the management API's 0.9->1.0 / v1alpha2->v1 bump was a pure version-label change with no schema drift, so a live conversion webhook isn't earning its operational cost yet (cert lifecycle, and coupling CRD read/write availability to operator pod health). Keep the Hub()/ConvertTo()/ConvertFrom() Go types as-is so switching to a real webhook later is a small, isolated change if a genuine breaking schema change is ever planned. - cmd/main.go: remove conversion webhook registration, ENABLE_WEBHOOKS gating, webhook readyz check, and the webhook TLS server/CertDir. - subscriptionplan_controller.go: make plan recovery-by-name reactive (only after the gateway returns 409 on create), matching subscription_controller.go, instead of proactively adopting any gateway-wide plan with a matching (non-unique) planName. - operator-crds.yaml: replace direct CRD-as-template rendering (which breaks `helm upgrade` for any CRD previously installed via the chart's native crds/ directory, since that path never carries Helm's ownership annotations) with a pre-install/pre-upgrade hook ConfigMap + Job that kubectl-applies the CRDs directly, bypassing Helm's ownership tracking entirely. Conversion strategy is now unconditionally None. - crd-manager-rbac.yaml: cluster-scoped RBAC for the apply-crds Job (CRDs aren't namespaced, so this can't ride on the namespace-scoped Role path). - Remove webhook-service.yaml and the webhook.* values/deployment wiring (port, cert volume/mount, ENABLE_WEBHOOKS env). - Chart.yaml: bump version for the CRD packaging/lifecycle change.
crd-manager-rbac.yaml was a plain (non-hook) resource, so on helm upgrade it only applied AFTER pre-install/pre-upgrade hooks ran — the apply-crds Job (a pre-upgrade hook) tried to use a ClusterRoleBinding that didn't exist yet on the very upgrade that introduces it, failing with: customresourcedefinitions.apiextensions.k8s.io "..." is forbidden: User "system:serviceaccount:<ns>:controller-manager" cannot get resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope Reproduced by installing the pre-PR chart (CRDs in crds/, v1alpha1 only) then helm upgrade --install to this chart, against a real rancher-desktop cluster. Fix: make the ClusterRole/ClusterRoleBinding pre-install,pre-upgrade hooks too, weighted before the ConfigMap (0) and apply-crds Job (1). Re-ran the same install-old/upgrade-to-new repro after the fix: upgrade succeeded, apply-crds Job completed and self-cleaned, all 12 CRDs ended up served at v1+v1alpha1 with conversion strategy None and v1 as storage, and a v1alpha1 SubscriptionPlan CR applied post-upgrade reconciled correctly.
…Ds; add schema identity test
… RestApi CRDs; enhance RBAC and cleanup job definitions
- Introduced CRDs for Subscription and SubscriptionPlan under the group gateway.api-platform.wso2.com. - Each CRD includes detailed specifications, status fields, and validation rules. - Updated NOTES.txt to reflect the installation method of CRDs. - Modified cleanup finalizer job to use a configurable service account name. - Removed deprecated RBAC configurations and CRD apply job templates to streamline the chart.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related to #2765
This pull request introduces the new
v1API group for the gateway-operator, adding first-class CRD types for API Gateway, API Key, and Certificate resources. It also establishes common type definitions, conversion hub methods, and updates the project configuration to register thev1resources. These changes lay the groundwork for stable CRD APIs, improving extensibility and future compatibility.New v1 API Resource Definitions:
APIGateway,ApiKey, andCertificatetypes and their associated spec/status fields in the newkubernetes/gateway-operator/api/v1package, providing CRD schemas for API management resources. [1] [2] [3]Common Types and Utilities:
SecretValueSourceandResourceStatusincommon_types.gofor consistent handling of secrets and resource status across CRDs.conversion.go, enabling CRD version conversion via webhooks.groupversion_info.goto register the newv1API group and scheme.Project Configuration:
kubernetes/gateway-operator/PROJECTto registerAPIGatewayandRestApiresources for bothv1andv1alpha1versions, ensuring the new types are recognized by the operator. [1] [2]