[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 3 commits into
Conversation
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ 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.
There was a problem hiding this comment.
Fixed in 1d10de7 — the list entry now links to api.mdx#gatewayapispec, matching the sibling *Spec links.
| 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.
There was a problem hiding this comment.
| 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.
There was a problem hiding this comment.
Moot as of 5fc8ebc — the tabs are removed and the step is plain kubectl again, so there's no nested-Tabs rendering to verify.
…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?
Per ctauchen's review on tigera#2798: docs convention is not to duplicate Helm flows on task pages, so drop the Helm/kubectl tabs and restore the kubectl-only enablement step, with a tip linking to the Helm installation reference. Slim the customize-page tip to a pointer at the same reference, and add a release-note entry for enabling Calico Ingress Gateway via gatewayAPI.enabled at Helm install time. The Helm installation reference changes are unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
@ctauchen Agreed — I checked the other task pages and none of them document a Helm enablement flow inline, so the tabs were off-convention. Restructured in 5fc8ebc along the lines you suggested:
Also updated the PR description to match the new scope and stripped the Claude Code footer per @electricjesus's note. |
…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>
…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>
Per ctauchen's review on tigera#2798: docs convention is not to duplicate Helm flows on task pages, so drop the Helm/kubectl tabs and restore the kubectl-only enablement step, with a tip linking to the Helm installation reference. Slim the customize-page tip to a pointer at the same reference, and add a release-note entry for enabling Calico Ingress Gateway via gatewayAPI.enabled at Helm install time. The Helm installation reference changes are unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
5fc8ebc to
b808b05
Compare
What
Documents the new ability to enable Calico Ingress Gateway (CIG) at Helm install time via the tigera-operator chart's
gatewayAPI.enabledtoggle. Enterprise-only, in the current ("next")calico-enterprise/docs.Following review feedback, this keeps the existing kubectl flow as the documented enablement process and records the Helm capability where our docs normally cover Helm: the Helm installation reference, plus short pointers and a release note.
Changes
reference/installation/helm_customization.mdx: adds Gateway API to the customizable-resources list and agatewayAPIblock to the samplevalues.yaml.networking/ingress-gateway/create-ingress-gateway.mdx: the enablement step stays kubectl-only; a tip notes that Helm installs can setgatewayAPI.enabled: trueinvalues.yaml, linking to the Helm installation reference.networking/ingress-gateway/customize-ingress-gateway.mdx: a tip notes that GatewayAPI spec fields can also be set at install time undergatewayAPI:invalues.yaml, linking to the Helm installation reference.release-notes/index.mdx: adds an enhancement entry for enabling CIG during Helm installation.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.