[APIP] Update Operator helm-chart#2749
Draft
DDH13 wants to merge 3 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 |
DDH13
changed the title
DDH13
changed the title
- 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.
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
1 participant
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.
This pull request introduces a new
v1API version for several core CRDs in the gateway operator, includingAPIGateway,ApiKey, andCertificate. It adds type definitions, status fields, and conversion hub implementations for these resources, enabling future-proofing and versioned schema evolution. Additionally, it updates the project configuration to register the newv1resources and enables conversion webhooks for seamless migration between versions.New v1 API types and conversion support:
API Resource Definitions
v1API type definitions forAPIGateway(apigateway_types.go),ApiKey(apikey_types.go),Certificate(certificate_types.go), and supporting types (common_types.go). These include detailed spec and status fields, validation, and comments to mirror the management API and improve CRD usability. [1] [2] [3] [4]v1resources (groupversion_info.go).Conversion Webhook and Versioning
v1resources inconversion.go, marking them as the canonical storage version for CRD conversion webhooks.PROJECTconfig to registerv1versions ofRestApiandAPIGateway, enabling conversion webhooks for these resources. [1] [2]These changes lay the foundation for supporting multiple CRD versions and enable seamless upgrades and schema evolution for the gateway operator.