Skip to content

[APIP] Update Operator helm-chart#2749

Draft
DDH13 wants to merge 3 commits into
wso2:mainfrom
DDH13:main.helm-1.2
Draft

[APIP] Update Operator helm-chart#2749
DDH13 wants to merge 3 commits into
wso2:mainfrom
DDH13:main.helm-1.2

Conversation

@DDH13

@DDH13 DDH13 commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

This pull request introduces a new v1 API version for several core CRDs in the gateway operator, including APIGateway, ApiKey, and Certificate. 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 new v1 resources and enables conversion webhooks for seamless migration between versions.

New v1 API types and conversion support:

  • API Resource Definitions

    • Added v1 API type definitions for APIGateway (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]
    • Introduced a versioned group registration and scheme builder for v1 resources (groupversion_info.go).
  • Conversion Webhook and Versioning

    • Implemented the conversion hub interfaces for all new v1 resources in conversion.go, marking them as the canonical storage version for CRD conversion webhooks.
    • Updated the PROJECT config to register v1 versions of RestApi and APIGateway, 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.

@coderabbitai

coderabbitai Bot commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 11c31c87-6189-41db-980e-e561eaaf12cd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@DDH13 DDH13 changed the title [APIP] Add Subscription CRDs with webhook support and Helm chart updates [APIP] Add Subscription CRDs and promote gateway-operator CRDs to v1 Jul 20, 2026
@DDH13 DDH13 changed the title [APIP] Add Subscription CRDs and promote gateway-operator CRDs to v1 [APIP] Update Operator helm-chart Jul 20, 2026
- 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.
DDH13 added 2 commits July 20, 2026 16:45
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant