feat: make cert-manager Gateway API ready#286
feat: make cert-manager Gateway API ready#286Tadas Sutkaitis (fitbeard) wants to merge 1 commit into
Conversation
Signed-off-by: Tadas Sutkaitis <tadas.sutkaitis@vexxhost.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 970d02303c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".
|
|
||
| _cert_manager_version_values: | ||
| extraArgs: | ||
| - --enable-gateway-api |
There was a problem hiding this comment.
Keep Gateway API opt-in until CRDs are guaranteed
For any playbook that selects cert-manager v1.15 before installing Gateway API CRDs, this unconditional --enable-gateway-api makes the cert-manager controller fail during startup: upstream cert-manager v1.15 pkg/controller/context.go:buildClients returns an error when EnableGatewayAPI is true and gateway.networking.k8s.io/v1 resources are absent. I checked this role has no dependency/order ensuring envoy_gateway or the Gateway API CRDs run first, and the cert_manager molecule scenario prepares only Kubernetes, so the standalone role can now deploy a CrashLooping controller instead of a healthy cert-manager release. Please make this opt-in or add an explicit CRD prerequisite/order before enabling it by default.
Useful? React with 👍 / 👎.
Merge only after Gateway API introduction in Atmosphere