[EV-6717] Document enabling Calico Ingress Gateway via the Helm gatewayAPI toggle#2798
[EV-6717] Document enabling Calico Ingress Gateway via the Helm gatewayAPI toggle#2798xiumozhan wants to merge 2 commits into
Conversation
…ayAPI toggle Add the Helm install-time path (gatewayAPI.enabled) for enabling Calico Ingress Gateway alongside the existing kubectl method, with the matching Helm values reference entry and sample, plus a customization note that GatewayAPI spec fields can be set under gatewayAPI in values.yaml. Enterprise-only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
❌ Deploy Preview for calico-docs-preview-next failed. Why did it fail? →
|
✅ Deploy Preview succeeded!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
Documents enabling Calico Ingress Gateway (CIG) via the tigera-operator Helm chart’s gatewayAPI.enabled toggle (install-time), alongside the existing post-install kubectl apply method, in Calico Enterprise “next” docs.
Changes:
- Adds Gateway API to the Helm customization reference and includes a
gatewayAPI:example block invalues.yaml. - Updates the “Create an ingress gateway” guide to present Helm vs kubectl enablement methods in tabs.
- Adds an install-time Helm tip to the ingress gateway customization guide.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| calico-enterprise/reference/installation/helm_customization.mdx | Adds Gateway API to the list of customizable resources and to the sample values.yaml. |
| calico-enterprise/networking/ingress-gateway/customize-ingress-gateway.mdx | Adds a tip about setting GatewayAPI spec fields via Helm values.yaml at install time. |
| calico-enterprise/networking/ingress-gateway/create-ingress-gateway.mdx | Adds Docusaurus tabs to show Helm vs kubectl methods for enabling Gateway API support. |
| - [Policy recommendation](api.mdx#policyrecommendationspec) | ||
| - [Authentication](api.mdx#authenticationspec) | ||
| - [Application layer](api.mdx#applicationlayerspec) | ||
| - [Gateway API (Calico Ingress Gateway)](api.mdx#gatewayapi) |
| The Tigera Operator creates the `tigera-secure` `GatewayAPI` resource as part of the installation. To customize the gateway, set any [`GatewayAPI` spec field](../../reference/installation/api.mdx#gatewayapi) under `gatewayAPI:` — for example, to [define additional gateway classes](customize-ingress-gateway.mdx#configure-multiple-gateway-classes): | ||
|
|
||
| ```yaml title='values.yaml' | ||
| gatewayAPI: | ||
| enabled: true | ||
| gatewayClasses: | ||
| - name: tigera-gateway-class | ||
| ``` |
electricjesus
left a comment
electricjesus
left a comment
There was a problem hiding this comment.
Thanks Patrick — docs read well and the tigera-secure naming lines up with the chart. A few small inline nits below, all non-blocking. One housekeeping ask: mind stripping the "🤖 Generated with Claude Code" footer from the PR description? We keep AI attribution out of tigera repo PR bodies.
| - [Policy recommendation](api.mdx#policyrecommendationspec) | ||
| - [Authentication](api.mdx#authenticationspec) | ||
| - [Application layer](api.mdx#applicationlayerspec) | ||
| - [Gateway API (Calico Ingress Gateway)](api.mdx#gatewayapi) |
There was a problem hiding this comment.
Nit: the rest of this list links to the *Spec anchors (e.g. #applicationlayerspec, #policyrecommendationspec). For consistency, link to api.mdx#gatewayapispec here. Both anchors resolve, so non-blocking.
| enabled: true | ||
| ``` | ||
|
|
||
| The Tigera Operator creates the `tigera-secure` `GatewayAPI` resource as part of the installation. To customize the gateway, set any [`GatewayAPI` spec field](../../reference/installation/api.mdx#gatewayapi) under `gatewayAPI:` — for example, to [define additional gateway classes](customize-ingress-gateway.mdx#configure-multiple-gateway-classes): |
There was a problem hiding this comment.
Two small things on this line:
- The link text says "spec field" but points to
#gatewayapi(the resource section).#gatewayapispeclands the reader on the spec fields and matches the rest of the docs. - The sentence offers "define additional gateway classes" as the example, but the YAML just below only sets the default
tigera-gateway-class— so it doesn't actually demonstrate an additional class. Either reword to "define gateway classes", or add a second class to the example so it matches the prose.
| 1. To enable Gateway API support, create a `GatewayAPI` resource with the name `tigera-secure`: | ||
| 1. Enable Gateway API support by creating a `GatewayAPI` resource named `tigera-secure`. You can enable it at install time with Helm, or at any time with `kubectl`. Both methods create the same `tigera-secure` resource and the default `tigera-gateway-class`. | ||
|
|
||
| <Tabs groupId="cig-enable"> |
There was a problem hiding this comment.
Worth previewing the rendered page — <Tabs> nested inside an ordered-list item can render oddly in Docusaurus (list numbering / indentation). Low risk, just confirm it looks right in the build.
…y class Per review on tigera#2798: point the Gateway API links at the GatewayAPISpec anchor (matching the sibling *Spec links and landing users on the spec fields), and add a second class to the values example so it actually demonstrates defining additional gateway classes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ctauchen
left a comment
ctauchen
left a comment
There was a problem hiding this comment.
Thanks for this, @xiumozhan.
I see from the tickets that we've added Helm support for CIG, which is the reason for this PR. But we don't tend to document Helm flows like this in our documentation. We have Helm install guides, tell people to take a look at values.yaml, and refer to the helm customization guide.
Without stong justifications, I'd be inclined to leave the CIG enablement process as-is (kubectl only). Update the customization page, add a release note, and perhaps add a note or link referring to this capability somewhere on the Create an ingress gateway page.
What are your thoughts here?
What
Documents how to enable Calico Ingress Gateway (CIG) at Helm install time using the tigera-operator chart's
gatewayAPI.enabledtoggle, alongside the existing post-installkubectl applymethod. Enterprise-only, in the current ("next")calico-enterprise/docs.Changes
networking/ingress-gateway/create-ingress-gateway.mdx: the enable step now presents both methods in tabs — Helm at install time (default) and kubectl after installation — both creating the sametigera-secureGatewayAPI resource and the defaulttigera-gateway-class.reference/installation/helm_customization.mdx: adds Gateway API to the customizable-resources list and agatewayAPIblock to the samplevalues.yaml.networking/ingress-gateway/customize-ingress-gateway.mdx: adds a tip noting that GatewayAPI spec fields can be set undergatewayAPI:invalues.yamlat install time.Dependency and timing
The
gatewayAPI.enabledchart toggle ships via calico-private PR #12357 (targets the next Calico Enterprise release). This docs change should merge in lockstep with that release so the instructions match the shipped chart.🤖 Generated with Claude Code