[APIP] Update Operator helm-chart#2749
Merged
Merged
Conversation
Contributor
|
Important Review skippedToo many files! This PR contains 110 files, which is 10 over the limit of 100. To get a review, narrow the scope: Upgrade to a paid plan to raise the limit. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (110)
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.
…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.
DDH13
marked this pull request as ready for review
July 21, 2026 11:56
DDH13
requested review from
AnuGayan,
Arshardh,
RakhithaRR,
Tharsanan1,
VirajSalaka,
chamilaadhi,
dushaniw,
malinthaprasan,
renuka-fernando,
tgtshanika,
tharikaGitHub and
tharindu1st
as code owners
July 21, 2026 11:56
DDH13
requested review from
CrowleyRajapakse,
HeshanSudarshana,
HiranyaKavishani,
Induwara04,
Krishanx92,
PasanT9,
Piumal1999,
Thushani-Jayasekera,
ashera96,
hisanhunais,
lasanthaS,
pubudu538,
senthuran16 and
thivindu
as code owners
July 21, 2026 11:56
Krishanx92
approved these changes
Jul 21, 2026
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
2 participants
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 stable, production-ready CRDs and types for key resources such asAPIGateway,ApiKey, andCertificate. It also updates the operator configuration to register these new APIs, and updates documentation to reference the new chart version. The new types provide improved structure, validation, and support for secrets and status management, aligning with Kubernetes best practices.The most important changes are:
API Group and Versioning
v1API group undergateway.api-platform.wso2.com, including group version registration and scheme setup ingroupversion_info.go. This establishesv1as the storage and conversion hub for the operator’s CRDs. [1] [2]PROJECTconfiguration to registerAPIGatewayandRestApiresources for bothv1andv1alpha1APIs, enabling dual-version support. [1] [2]New CRD Types
APIGateway,ApiKey, andCertificatetypes in the newv1API, with detailed spec and status fields, improved validation, and support for referencing secrets and config maps. These types are now the canonical schema for these resources. [1] [2] [3]v1CRDs, improving consistency and security.Documentation and Chart Updates
README.mdto reference the new Helm chart version0.10.0, ensuring users install the operator with support for the new APIs.These changes lay the foundation for stable, production-grade CRDs and future extensibility in the gateway-operator.