Docs for using GatewayAPI#169
Merged
RakhithaRR merged 9 commits intowso2:mainfrom Mar 16, 2026
Merged
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR updates documentation to make Envoy Gateway (Gateway API) the default, recommended routing option while marking NGINX Ingress Controller as deprecated and disabled by default; numerous pattern guides, README files, sample manifests/values, and one default_values.yaml default were updated accordingly. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/am-pattern-2-all-in-one_GW/README.md`:
- Around line 206-213: The README mentions docs/assets/sample-gateway.yaml but
the apply command uses gateway-manifest.yaml; update the apply command to
reference the same file path/name (e.g., replace "gateway-manifest.yaml" with
"docs/assets/sample-gateway.yaml") so the sample manifest and kubectl apply
command use an identical filename; ensure this change touches the text around
the kubectl apply example in the README (the block containing the kubectl
command).
In `@docs/am-pattern-3-ACP_TM_GW/README.md`:
- Around line 247-253: The README references two different manifest filenames
which is inconsistent: it points to docs/assets/sample-gateway.yaml but the
kubectl example uses gateway-manifest.yaml; update the kubectl apply example in
the README (the block under the sample manifest note) to use the same path
docs/assets/sample-gateway.yaml (replace gateway-manifest.yaml with
docs/assets/sample-gateway.yaml) so the quick-start command matches the
referenced sample manifest.
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 220-224: Update the Helm install command in the README where the
command `helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f
default_gw_values.yaml -n <namespace>` appears: replace the incorrect chart name
`wso2/wso2-gw` with the correct chart `wso2/wso2am-gw` so the command reads
`helm install apim-gw wso2/wso2am-gw ...`; leave the rest of the command (flags
and version) unchanged.
In `@docs/am-pattern-5-all-in-one_GW_KM/README.md`:
- Around line 197-201: The Helm install for the KM reuses the release name
"apim" which conflicts with the earlier all-in-one install; update the second
helm install command (the line containing helm install apim wso2/wso2am-acp
--version 4.6.0-1 -f default_km_values.yaml -n <namespace>) to use a distinct
release name (for example "apim-km" or similar) so releases are unique within
the namespace and the install will succeed.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 659d1783-5556-4df9-92b3-31d803654269
📒 Files selected for processing (8)
README.mddocs/README.mddocs/am-pattern-0-all-in-one/README.mddocs/am-pattern-1-all-in-one-HA/README.mddocs/am-pattern-2-all-in-one_GW/README.mddocs/am-pattern-3-ACP_TM_GW/README.mddocs/am-pattern-4-ACP_TM_GW_KM/README.mddocs/am-pattern-5-all-in-one_GW_KM/README.md
There was a problem hiding this comment.
Actionable comments posted: 9
♻️ Duplicate comments (1)
docs/am-pattern-4-ACP_TM_GW_KM/README.md (1)
231-233:⚠️ Potential issue | 🔴 CriticalFix the gateway chart name in the install command.
Line 232 uses
wso2/wso2-gw, which is inconsistent with the gateway chart naming used in this repo and will fail for users following the command.🛠️ Proposed doc fix
- helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim + helm install apim-gw wso2/wso2am-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md` around lines 231 - 233, The helm install command string "helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim" uses the wrong chart name; update that command to use the repository's actual gateway chart name (replace "wso2/wso2-gw" with the gateway chart identifier used elsewhere in this repo) so the install command matches the repo's chart naming and will succeed for users.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/am-pattern-0-all-in-one/README.md`:
- Around line 152-174: The docs introduce kubernetes.gatewayAPI.* and
backendTLSPolicy.* keys that don't exist in the chart values; update the README
to match the actual values schema or update the chart to expose those keys.
Specifically, either replace the example block with the existing
kubernetes.ingress and kubernetes.route keys (as defined in
all-in-one/values.yaml) or add the corresponding kubernetes.gatewayAPI and
backendTLSPolicy entries to the chart values and schema so the documented keys
(kubernetes.gatewayAPI, gatewayName, management, gateway, websocket, websub,
backendTLSPolicy) match the real configuration.
- Line 18: Fix the typo in the README table of contents entry that currently
reads "Ingresss controller" — update the label to "Ingress controller" in the
line referencing "[1.1 Add Gateway API controller or Ingresss controller]" so
the TOC and anchor text match the correct spelling.
In `@docs/am-pattern-1-all-in-one-HA/README.md`:
- Around line 142-146: The helm install command that targets the
envoy-gateway-system namespace (the command starting with "helm install
envoy-gateway ... -n envoy-gateway-system") should include the
--create-namespace flag so the namespace is created if it doesn't exist; update
that helm install invocation to add --create-namespace immediately before or
after the -n envoy-gateway-system argument.
In `@docs/am-pattern-2-all-in-one_GW/README.md`:
- Around line 158-196: The documentation uses inconsistent namespaces: the
secret creation (kubectl create secret generic apim-keystore-secret) and the
helm installs (helm install apim ... and helm install apim-gw ...) omit the
target namespace created by kubectl create namespace apim; update the commands
so they consistently target the apim namespace (e.g., add -n apim or --namespace
apim to the kubectl create secret generic apim-keystore-secret command and to
both helm install apim and helm install apim-gw invocations) and ensure the
kubectl apply -f docs/assets/sample-gateway.yaml step also references -n apim if
it should run in that namespace (sample-gateway.yaml).
In `@docs/am-pattern-3-ACP_TM_GW/README.md`:
- Around line 184-187: The Helm install command shown (helm install
envoy-gateway oci://docker.io/envoyproxy/gateway-helm --version v1.7.0 -n
envoy-gateway-system ...) assumes the namespace exists; update the invocation to
either include --create-namespace or explicitly create the namespace beforehand
(e.g., kubectl create namespace envoy-gateway-system) so the install into
envoy-gateway-system will not fail.
- Around line 172-179: The keystore secret is being created before the apim
namespace exists and without specifying a namespace, so it lands in default and
later releases targeting apim cannot find it; update the README to create the
namespace first using the existing kubectl create namespace apim step (kubectl
create namespace apim) and then create the secret with the namespace flag or
after the namespace exists by running the kubectl create secret generic
apim-keystore-secret command against the apim namespace (use -n apim or run it
after creating the namespace).
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 183-190: The secret creation command creates apim-keystore-secret
in the current namespace, causing a mismatch with the apim namespace used by the
deployments; update the command that creates apim-keystore-secret (and any other
secret commands like client-truststore.jks) to target the apim namespace by
adding the namespace flag (e.g., use --namespace or -n apim) so the secret
exists in the same namespace as the deployments that mount it.
In `@docs/am-pattern-5-all-in-one_GW_KM/README.md`:
- Around line 260-266: The README references docs/assets/sample-gateway.yaml but
the kubectl apply command uses docs/assets/gateway.yaml; update one of these so
both use the same filename—either change the mention of sample-gateway.yaml to
docs/assets/gateway.yaml or change the apply command to use
docs/assets/sample-gateway.yaml—so the manifest reference and the kubectl apply
command are identical and reproducible.
In `@README.md`:
- Line 3: Update the sentence containing the phrase "APIM related" to use a
compound adjective for readability by replacing "APIM related" with
"APIM-related" in the README (look for the line that currently reads "This repo
will be used to maintain APIM related helm charts").
---
Duplicate comments:
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 231-233: The helm install command string "helm install apim-gw
wso2/wso2-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim" uses the wrong
chart name; update that command to use the repository's actual gateway chart
name (replace "wso2/wso2-gw" with the gateway chart identifier used elsewhere in
this repo) so the install command matches the repo's chart naming and will
succeed for users.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3949083e-a433-4b08-b031-53452a28f9b2
📒 Files selected for processing (9)
README.mddocs/README.mddocs/am-pattern-0-all-in-one/README.mddocs/am-pattern-0-all-in-one/default_values.yamldocs/am-pattern-1-all-in-one-HA/README.mddocs/am-pattern-2-all-in-one_GW/README.mddocs/am-pattern-3-ACP_TM_GW/README.mddocs/am-pattern-4-ACP_TM_GW_KM/README.mddocs/am-pattern-5-all-in-one_GW_KM/README.md
✅ Files skipped from review due to trivial changes (1)
- docs/am-pattern-0-all-in-one/default_values.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/README.md
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (9)
docs/am-pattern-0-all-in-one/README.md (2)
94-94:⚠️ Potential issue | 🟡 MinorInconsistent claim about default configuration.
This line states "The Helm chart uses Gateway API by default," but this contradicts the evidence from
default_values.yaml(lines 131–180), which shows onlykubernetes.ingressconfiguration with NGINX-specific settings and nokubernetes.gatewayAPIblock.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-0-all-in-one/README.md` at line 94, The README incorrectly claims "The Helm chart uses Gateway API by default" while default_values.yaml only defines kubernetes.ingress (NGINX) and lacks a kubernetes.gatewayAPI block; update the README line to reflect the actual default (Ingress/NGINX) or add a kubernetes.gatewayAPI default in default_values.yaml to match the README—locate references to kubernetes.ingress and kubernetes.gatewayAPI (and the README sentence in docs/am-pattern-0-all-in-one/README.md) and either change the README wording to "The Helm chart uses Ingress (NGINX) by default" or add a default kubernetes.gatewayAPI section in default_values.yaml consistent with the chart behavior.
107-107:⚠️ Potential issue | 🟡 MinorVerify default routing configuration.
This line claims "the charts are configured to use the Envoy Gateway by default," but the schema evidence from
default_values.yamlindicates otherwise (see comment on lines 53-55).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-0-all-in-one/README.md` at line 107, The README claim that "the charts are configured to use the Envoy Gateway by default" conflicts with the defaults in default_values.yaml (see the ingress/gateway-related keys around the commented section at lines ~53-55); reconcile by either updating default_values.yaml to set the Envoy Gateway as the default (modify the gateway-enabled/ingress-enabled boolean flags and any Gateway API vs Ingress settings in the chart defaults) or update README.md to accurately state which controller is enabled by default (referencing "Envoy Gateway" and "NGINX Ingress Controller" and the specific Helm chart values such as gateway.enabled and ingress.enabled) so the documentation matches the actual chart defaults.docs/am-pattern-4-ACP_TM_GW_KM/README.md (2)
195-198:⚠️ Potential issue | 🟠 MajorAdd
--create-namespaceto ensure the namespace exists.The Envoy Gateway installation targets
envoy-gateway-systemwithout creating it first. Add the--create-namespaceflag.🛠️ Proposed fix
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \ --version v1.7.0 -n envoy-gateway-system \ --set config.envoyGateway.extensionApis.enableBackend=true \ - --set envoyGateway.gateway.experimentalFeatures.enabled=true + --set envoyGateway.gateway.experimentalFeatures.enabled=true \ + --create-namespace🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md` around lines 195 - 198, The helm install command that deploys Envoy Gateway (the "helm install envoy-gateway ... -n envoy-gateway-system" invocation) doesn't create the target namespace; update that command to include the --create-namespace flag so Helm will create envoy-gateway-system if it doesn't exist, keeping the existing flags like --version v1.7.0 and the --set options unchanged.
231-233:⚠️ Potential issue | 🔴 CriticalCorrect the chart name to
wso2/wso2am-gw.The install command uses
wso2/wso2-gw, but the correct chart name iswso2/wso2am-gw(as referenced elsewhere in this repository).🛠️ Proposed fix
- helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim + helm install apim-gw wso2/wso2am-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md` around lines 231 - 233, Update the Helm install command so the chart name matches the repository references: replace the chart identifier "wso2/wso2-gw" in the helm command `helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim` with the correct chart name "wso2/wso2am-gw" so the command becomes `helm install apim-gw wso2/wso2am-gw ...`.docs/am-pattern-3-ACP_TM_GW/README.md (2)
184-187:⚠️ Potential issue | 🟠 MajorAdd
--create-namespaceto avoid installation failure.The Helm install command targets
envoy-gateway-systembut doesn't create it. Add--create-namespaceto ensure the step succeeds on clean clusters.🛠️ Proposed fix
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \ --version v1.7.0 -n envoy-gateway-system \ --set config.envoyGateway.extensionApis.enableBackend=true \ - --set envoyGateway.gateway.experimentalFeatures.enabled=true + --set envoyGateway.gateway.experimentalFeatures.enabled=true \ + --create-namespace🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-3-ACP_TM_GW/README.md` around lines 184 - 187, The Helm install command invoking "helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm --version v1.7.0 -n envoy-gateway-system" should include the --create-namespace flag so the namespace envoy-gateway-system is created on clean clusters; update that helm install invocation to add --create-namespace alongside the existing flags (--version, -n, --set ...) to ensure installation does not fail due to a missing namespace.
170-179:⚠️ Potential issue | 🔴 CriticalCreate the namespace before the secret.
Line 172 creates the secret in the
apimnamespace, but the namespace isn't created until Line 178. The secret creation will fail because the namespace doesn't exist yet.🛠️ Proposed fix
Reorder the steps:
-- Follow the steps in [1.2 Mount Keystore and Truststore](`#12-mount-keystore-and-truststore`) to create the truststore and keystore. If you want to use the WSO2 default keystore and truststore, you can find them in the `repository/resources/security` directory of the product pack. Navigate to this location and run the following command to create the secret: - - ```bash - kubectl create secret generic apim-keystore-secret --from-file=wso2carbon.jks --from-file=client-truststore.jks -n apim - ``` - - Create a namespace for the deployment. ```bash kubectl create namespace apim
+- Follow the steps in 1.2 Mount Keystore and Truststore to create the truststore and keystore. If you want to use the WSO2 default keystore and truststore, you can find them in the
repository/resources/securitydirectory of the product pack. Navigate to this location and run the following command to create the secret:
+
- kubectl create secret generic apim-keystore-secret --from-file=wso2carbon.jks --from-file=client-truststore.jks -n apim
</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/am-pattern-3-ACP_TM_GW/README.mdaround lines 170 - 179, The secret
creation command "kubectl create secret generic apim-keystore-secret
--from-file=wso2carbon.jks --from-file=client-truststore.jks -n apim" is
executed before the "kubectl create namespace apim" step, which will fail;
reorder the steps so the namespace is created first (run "kubectl create
namespace apim" before creating the apim-keystore-secret), and optionally
reference the existing instructions in the "1.2 Mount Keystore and Truststore"
section when instructing users to create the keystore/truststore and then run
the secret creation command.</details> </blockquote></details> <details> <summary>docs/am-pattern-5-all-in-one_GW_KM/README.md (1)</summary><blockquote> `186-189`: _⚠️ Potential issue_ | _🟠 Major_ **Add `--create-namespace` flag.** The Envoy Gateway installation targets `envoy-gateway-system` without ensuring it exists. Add the `--create-namespace` flag to make the installation reliable. <details> <summary>🛠️ Proposed fix</summary> ```diff helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \ --version v1.7.0 -n envoy-gateway-system \ --set config.envoyGateway.extensionApis.enableBackend=true \ - --set envoyGateway.gateway.experimentalFeatures.enabled=true + --set envoyGateway.gateway.experimentalFeatures.enabled=true \ + --create-namespace🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-5-all-in-one_GW_KM/README.md` around lines 186 - 189, The helm install command for Envoy Gateway targets the namespace envoy-gateway-system but doesn't ensure it exists; update the helm install invocation (the line starting with "helm install envoy-gateway ... -n envoy-gateway-system") to include the --create-namespace flag so Helm will create envoy-gateway-system if missing, preserving the existing --version and --set flags.docs/am-pattern-2-all-in-one_GW/README.md (2)
155-159:⚠️ Potential issue | 🔴 CriticalCreate the secret after the namespace and specify the target namespace.
Line 158 creates the secret before the namespace exists (Line 164) and without the
-n apimflag, so it lands in thedefaultnamespace. Later Helm installs targeting theapimnamespace will fail because they cannot find the secret.🛠️ Proposed fix
Reorder the steps and add the namespace flag:
-- Follow the steps in [1.2 Mount Keystore and Truststore](`#12-mount-keystore-and-truststore`) to create the truststore and keystore. If you want to use the WSO2 default keystore and truststore, you can find them in the `repository/resources/security` directory of the product pack. Navigate to this location and run the following command to create the secret: - - ```bash - kubectl create secret generic apim-keystore-secret --from-file=wso2carbon.jks --from-file=client-truststore.jks - ``` - - Create a namespace for the deployment. ```bash kubectl create namespace apim
+- Follow the steps in 1.2 Mount Keystore and Truststore to create the truststore and keystore. If you want to use the WSO2 default keystore and truststore, you can find them in the
repository/resources/securitydirectory of the product pack. Navigate to this location and run the following command to create the secret:
+
- kubectl create secret generic apim-keystore-secret --from-file=wso2carbon.jks --from-file=client-truststore.jks -n apim
</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/am-pattern-2-all-in-one_GW/README.mdaround lines 155 - 159, Move the
namespace creation step before creating the Kubernetes secret and create the
secret in the correct namespace by adding the target namespace flag;
specifically ensure you create the namespace (apim) first and then run the
creation of the secret named apim-keystore-secret with the -n apim flag so the
secret is placed into the apim namespace rather than default.</details> --- `167-174`: _⚠️ Potential issue_ | _🟠 Major_ **Add `--create-namespace` flag to the Envoy Gateway installation.** The Helm install targets the `envoy-gateway-system` namespace but doesn't create it. On a clean cluster, this step will fail. <details> <summary>🛠️ Proposed fix</summary> ```diff helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \ --version v1.7.0 -n envoy-gateway-system \ --set config.envoyGateway.extensionApis.enableBackend=true \ - --set envoyGateway.gateway.experimentalFeatures.enabled=true + --set envoyGateway.gateway.experimentalFeatures.enabled=true \ + --create-namespace🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-2-all-in-one_GW/README.md` around lines 167 - 174, The Helm install command for the Envoy Gateway (the invocation starting with "helm install envoy-gateway ... --version v1.7.0 -n envoy-gateway-system") may fail on a clean cluster because the target namespace "envoy-gateway-system" is not created; update that helm install invocation to add the --create-namespace flag so Helm will create the namespace automatically when installing the release.
🧹 Nitpick comments (2)
docs/am-pattern-0-all-in-one/README.md (2)
367-367: Clarify terminology: "Gateway API" vs "Gateway resource".The phrase "external IP (ADDRESS) of the Gateway API" is slightly ambiguous. "Gateway API" typically refers to the Kubernetes API specification itself, whereas "Gateway resource" or "Gateway" refers to the specific Kubernetes resource being deployed. Consider rephrasing to "external IP (ADDRESS) of the Gateway resource" for precision.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-0-all-in-one/README.md` at line 367, The wording is ambiguous: replace "external IP (ADDRESS) of the Gateway API" with "external IP (ADDRESS) of the Gateway resource" (or similar) so the README refers to the specific Kubernetes Gateway resource rather than the Gateway API specification; update the sentence that mentions "Gateway API" to use "Gateway resource" (search for the exact phrase "external IP (ADDRESS) of the Gateway API" to locate the line).
272-272: Consider making the section reference more specific.The phrase "under the Kubernetes Gateway API or Ingress section" is somewhat vague. Consider specifying the exact section numbers or paths, such as "under section 1.1 (Gateway API controller or Ingress controller)" to help users locate the configuration more easily.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-0-all-in-one/README.md` at line 272, The sentence "If you need to change the hostnames, update them under the Kubernetes Gateway API or Ingress section." is vague; update this sentence to point to the exact section or path so readers can find it quickly — e.g., replace it with "If you need to change the hostnames, update them in section 1.1 (Gateway API controller or Ingress controller) or the 'Kubernetes Gateway API / Ingress' subsection of this README." Refer to the existing sentence text to locate and replace it.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/am-pattern-0-all-in-one/README.md`:
- Around line 53-55: Update the README text to reflect actual defaults: state
that neither Envoy Gateway (kubernetes.gatewayAPI) nor NGINX Ingress
(kubernetes.ingress) is enabled by default and users must explicitly enable one
when deploying; reference the Helm values by name (kubernetes.ingress.enabled:
false and the absence of a kubernetes.gatewayAPI entry) so readers know where to
change defaults, or alternatively update the Helm chart to add and enable
kubernetes.gatewayAPI if you intend Gateway to be the default.
- Around line 153-175: The README references kubernetes.gatewayAPI.* and
backendTLSPolicy.* keys that don't exist in the chart; either add those
configuration blocks to the chart (extend the values.yaml with
kubernetes.gatewayAPI and backendTLSPolicy sections and update the Helm
templates to consume them) or remove/update the README snippet to document the
real supported keys (kubernetes.ingress and kubernetes.route plus
openshift/ingressClass/securityContext/configMaps) so users only see valid
paths; locate and change the values.yaml entries and any templates that should
render gateway API/ backend TLS behavior or edit the README snippet to reflect
ingress/route usage accordingly.
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 180-190: The secret creation step runs before the namespace
exists, causing failure; move the "kubectl create namespace apim" step to come
before the "kubectl create secret generic apim-keystore-secret ... -n apim" step
so the namespace is created first, i.e., reorder the two steps in README.md so
the namespace creation precedes the secret creation (refer to the "kubectl
create namespace apim" and "kubectl create secret generic apim-keystore-secret"
lines).
In `@docs/am-pattern-5-all-in-one_GW_KM/README.md`:
- Around line 171-181: Reorder the steps so the namespace is created before
creating the secret and add the namespace flag to the kubectl secret command:
move the "kubectl create namespace <namespace>" step ahead of the secret
creation and update the secret command to "kubectl create secret generic
apim-keystore-secret --from-file=wso2carbon.jks
--from-file=client-truststore.jks -n <namespace>" (replace <namespace> or use
"apim" as appropriate) to ensure the secret is created in the intended namespace
rather than default.
---
Duplicate comments:
In `@docs/am-pattern-0-all-in-one/README.md`:
- Line 94: The README incorrectly claims "The Helm chart uses Gateway API by
default" while default_values.yaml only defines kubernetes.ingress (NGINX) and
lacks a kubernetes.gatewayAPI block; update the README line to reflect the
actual default (Ingress/NGINX) or add a kubernetes.gatewayAPI default in
default_values.yaml to match the README—locate references to kubernetes.ingress
and kubernetes.gatewayAPI (and the README sentence in
docs/am-pattern-0-all-in-one/README.md) and either change the README wording to
"The Helm chart uses Ingress (NGINX) by default" or add a default
kubernetes.gatewayAPI section in default_values.yaml consistent with the chart
behavior.
- Line 107: The README claim that "the charts are configured to use the Envoy
Gateway by default" conflicts with the defaults in default_values.yaml (see the
ingress/gateway-related keys around the commented section at lines ~53-55);
reconcile by either updating default_values.yaml to set the Envoy Gateway as the
default (modify the gateway-enabled/ingress-enabled boolean flags and any
Gateway API vs Ingress settings in the chart defaults) or update README.md to
accurately state which controller is enabled by default (referencing "Envoy
Gateway" and "NGINX Ingress Controller" and the specific Helm chart values such
as gateway.enabled and ingress.enabled) so the documentation matches the actual
chart defaults.
In `@docs/am-pattern-2-all-in-one_GW/README.md`:
- Around line 155-159: Move the namespace creation step before creating the
Kubernetes secret and create the secret in the correct namespace by adding the
target namespace flag; specifically ensure you create the namespace (apim) first
and then run the creation of the secret named apim-keystore-secret with the -n
apim flag so the secret is placed into the apim namespace rather than default.
- Around line 167-174: The Helm install command for the Envoy Gateway (the
invocation starting with "helm install envoy-gateway ... --version v1.7.0 -n
envoy-gateway-system") may fail on a clean cluster because the target namespace
"envoy-gateway-system" is not created; update that helm install invocation to
add the --create-namespace flag so Helm will create the namespace automatically
when installing the release.
In `@docs/am-pattern-3-ACP_TM_GW/README.md`:
- Around line 184-187: The Helm install command invoking "helm install
envoy-gateway oci://docker.io/envoyproxy/gateway-helm --version v1.7.0 -n
envoy-gateway-system" should include the --create-namespace flag so the
namespace envoy-gateway-system is created on clean clusters; update that helm
install invocation to add --create-namespace alongside the existing flags
(--version, -n, --set ...) to ensure installation does not fail due to a missing
namespace.
- Around line 170-179: The secret creation command "kubectl create secret
generic apim-keystore-secret --from-file=wso2carbon.jks
--from-file=client-truststore.jks -n apim" is executed before the "kubectl
create namespace apim" step, which will fail; reorder the steps so the namespace
is created first (run "kubectl create namespace apim" before creating the
apim-keystore-secret), and optionally reference the existing instructions in the
"1.2 Mount Keystore and Truststore" section when instructing users to create the
keystore/truststore and then run the secret creation command.
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 195-198: The helm install command that deploys Envoy Gateway (the
"helm install envoy-gateway ... -n envoy-gateway-system" invocation) doesn't
create the target namespace; update that command to include the
--create-namespace flag so Helm will create envoy-gateway-system if it doesn't
exist, keeping the existing flags like --version v1.7.0 and the --set options
unchanged.
- Around line 231-233: Update the Helm install command so the chart name matches
the repository references: replace the chart identifier "wso2/wso2-gw" in the
helm command `helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f
default_gw_values.yaml -n apim` with the correct chart name "wso2/wso2am-gw" so
the command becomes `helm install apim-gw wso2/wso2am-gw ...`.
In `@docs/am-pattern-5-all-in-one_GW_KM/README.md`:
- Around line 186-189: The helm install command for Envoy Gateway targets the
namespace envoy-gateway-system but doesn't ensure it exists; update the helm
install invocation (the line starting with "helm install envoy-gateway ... -n
envoy-gateway-system") to include the --create-namespace flag so Helm will
create envoy-gateway-system if missing, preserving the existing --version and
--set flags.
---
Nitpick comments:
In `@docs/am-pattern-0-all-in-one/README.md`:
- Line 367: The wording is ambiguous: replace "external IP (ADDRESS) of the
Gateway API" with "external IP (ADDRESS) of the Gateway resource" (or similar)
so the README refers to the specific Kubernetes Gateway resource rather than the
Gateway API specification; update the sentence that mentions "Gateway API" to
use "Gateway resource" (search for the exact phrase "external IP (ADDRESS) of
the Gateway API" to locate the line).
- Line 272: The sentence "If you need to change the hostnames, update them under
the Kubernetes Gateway API or Ingress section." is vague; update this sentence
to point to the exact section or path so readers can find it quickly — e.g.,
replace it with "If you need to change the hostnames, update them in section 1.1
(Gateway API controller or Ingress controller) or the 'Kubernetes Gateway API /
Ingress' subsection of this README." Refer to the existing sentence text to
locate and replace it.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5cbcb2ee-6ebc-46b8-8a5f-f985f5f3dc36
📒 Files selected for processing (6)
docs/am-pattern-0-all-in-one/README.mddocs/am-pattern-1-all-in-one-HA/README.mddocs/am-pattern-2-all-in-one_GW/README.mddocs/am-pattern-3-ACP_TM_GW/README.mddocs/am-pattern-4-ACP_TM_GW_KM/README.mddocs/am-pattern-5-all-in-one_GW_KM/README.md
There was a problem hiding this comment.
Actionable comments posted: 7
♻️ Duplicate comments (2)
docs/am-pattern-3-ACP_TM_GW/README.md (1)
184-188:⚠️ Potential issue | 🟠 MajorEnsure
envoy-gateway-systemexists in minimal setup.This minimal-path install omits
--create-namespace, so it can fail on a clean cluster.🛠️ Suggested fix
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \ --version v1.7.0 -n envoy-gateway-system \ --set config.envoyGateway.extensionApis.enableBackend=true \ - --set envoyGateway.gateway.experimentalFeatures.enabled=true + --set envoyGateway.gateway.experimentalFeatures.enabled=true \ + --create-namespace🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-3-ACP_TM_GW/README.md` around lines 184 - 188, The helm install command shown (helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm --version v1.7.0 -n envoy-gateway-system ...) can fail on a clean cluster because the namespace envoy-gateway-system may not exist; either create the namespace first (kubectl create namespace envoy-gateway-system) or add --create-namespace to the helm install invocation so the namespace is created automatically.docs/am-pattern-4-ACP_TM_GW_KM/README.md (1)
231-233:⚠️ Potential issue | 🔴 CriticalUse the correct GW chart name in the install command.
wso2/wso2-gwis inconsistent with the gateway chart naming used in this repo (wso2/wso2am-gw), so this quick-start step is likely to fail.🛠️ Suggested fix
- helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim + helm install apim-gw wso2/wso2am-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md` around lines 231 - 233, The Helm install command uses the wrong chart name; update the command string in the README snippet (the helm install invocation) to use the repository chart name wso2/wso2am-gw instead of wso2/wso2-gw (e.g., change "helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim" to use wso2/wso2am-gw) and verify the --version and values file remain accurate.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/am-pattern-2-all-in-one_GW/README.md`:
- Line 198: The README references kubernetes.gatewayAPI.* settings that don’t
exist in the chart values, causing the documented config path to be
non-functional; add the missing gateway API keys to the chart defaults and/or
align templates to existing keys. Specifically, add kubernetes.gatewayAPI:
{enabled: false, controller: "", class: ""} (or other necessary flags) into
all-in-one/default_values.yaml and all-in-one/values.yaml, and update templates
that render Ingress/Route (e.g., templates/ingress.yaml, templates/route.yaml or
any gateway-related helpers) to use .Values.kubernetes.gatewayAPI.enabled and
related fields; alternatively, if you prefer not to add keys, update the README
to point to the actual keys used by those templates so documentation and chart
values remain consistent.
- Around line 170-174: The helm install command targets the namespace
envoy-gateway-system but does not ensure it exists; either create the namespace
beforehand or add Helm's namespace creation flag: update the install step that
uses release name "envoy-gateway" and namespace "envoy-gateway-system" to create
the namespace (e.g., run a namespace creation step for envoy-gateway-system or
add --create-namespace to the helm install invocation) so the install won't fail
in fresh clusters.
In `@docs/am-pattern-3-ACP_TM_GW/README.md`:
- Around line 279-306: The documented kubernetes.gatewayAPI.* keys (e.g.,
gatewayAPI.enabled, gatewayName, defaultConfigMapCreation, management.*,
gateway.*, websocket.*, websub.*, backendTLSPolicy.*, backendTrafficPolicy.*)
are not actually used by the chart templates — the template
wso2am-gateway-ingress.yaml still renders legacy Ingress. Update the chart
templates to conditionally render Gateway API resources when
kubernetes.gatewayAPI.enabled is true (use gatewayName, hostnames, and
sub-objects for management/gateway/websocket/websub), wire
backendTLSPolicy.caCertificateConfigMap and hostname into TLS configuration, and
honor backendTrafficPolicy.cookie.name/ttl; alternatively, if Gateway API is not
supported, remove or change the README example to reflect the actual supported
keys so the docs aren’t a silent no-op.
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 255-256: Update the kubectl command that creates the TLS secret so
it targets the deployment namespace: modify the shown command "kubectl create
secret tls my-tls-secret --key <private key filename> --cert <certificate
filename>" to include the namespace flag (e.g., add -n <namespace> or
--namespace=<namespace>) or reference a placeholder like <target-namespace> so
the secret is created in the same namespace as your Gateway/Ingress resources.
- Around line 195-199: The README shows the helm install command targeting the
namespace envoy-gateway-system but doesn't create that namespace; update the
instructions to create the namespace before installation (e.g., add a step to
create envoy-gateway-system) or modify the helm install invocation to create the
namespace for you (use Helm's create-namespace behavior), referencing the
existing helm install command and the namespace name envoy-gateway-system so
readers won't hit failures on fresh clusters.
In `@docs/am-pattern-5-all-in-one_GW_KM/README.md`:
- Line 43: The "About" description currently states "separating the Traffic
Manager and Gateway from the Control Plane" which conflicts with Pattern 5 being
an all-in-one deployment with separate GW/KM components; update the sentence in
the README heading/intro (the line that currently reads "separating the Traffic
Manager and Gateway from the Control Plane") to explicitly state that this
pattern is an all-in-one API Manager deployment with the Gateway and Key Manager
extracted as separate components (e.g., "Pattern 5: all-in-one API Manager with
Gateway and Key Manager deployed as separate components"), and ensure any
adjacent descriptive text mentions the GW/KM extraction instead of implying full
separation from the control plane.
- Around line 186-190: Summary: The provided helm install command targets the
envoy-gateway-system namespace but doesn't create it. Fix: ensure the namespace
exists before installing by either adding the Helm flag --create-namespace to
the existing helm install envoy-gateway command (so helm install envoy-gateway
... -n envoy-gateway-system --create-namespace ...) or precede the install with
a kubectl create namespace envoy-gateway-system (or kubectl apply -f - with a
Namespace manifest); update the README's helm install block accordingly to
include one of these options so the install succeeds on a minimal cluster.
---
Duplicate comments:
In `@docs/am-pattern-3-ACP_TM_GW/README.md`:
- Around line 184-188: The helm install command shown (helm install
envoy-gateway oci://docker.io/envoyproxy/gateway-helm --version v1.7.0 -n
envoy-gateway-system ...) can fail on a clean cluster because the namespace
envoy-gateway-system may not exist; either create the namespace first (kubectl
create namespace envoy-gateway-system) or add --create-namespace to the helm
install invocation so the namespace is created automatically.
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 231-233: The Helm install command uses the wrong chart name;
update the command string in the README snippet (the helm install invocation) to
use the repository chart name wso2/wso2am-gw instead of wso2/wso2-gw (e.g.,
change "helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f
default_gw_values.yaml -n apim" to use wso2/wso2am-gw) and verify the --version
and values file remain accurate.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e681d97b-3827-47f2-84b3-76743414be9d
📒 Files selected for processing (4)
docs/am-pattern-2-all-in-one_GW/README.mddocs/am-pattern-3-ACP_TM_GW/README.mddocs/am-pattern-4-ACP_TM_GW_KM/README.mddocs/am-pattern-5-all-in-one_GW_KM/README.md
There was a problem hiding this comment.
Actionable comments posted: 11
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/am-pattern-1-all-in-one-HA/README.md (1)
268-275:⚠️ Potential issue | 🟠 MajorIngress example uses a non-existent section name for this chart.
Line 268 uses
ingress.controlPlane, but inall-in-one/values.yamlthe key isingress.management(all-in-one/values.yaml:148+). This example will misconfigure hostnames if copied as-is.Suggested doc fix
- controlPlane: + management: hostname: "am.wso2.com" annotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-1-all-in-one-HA/README.md` around lines 268 - 275, The README ingress example uses ingress.controlPlane which doesn't match the chart's values key ingress.management; update the snippet in README.md to use ingress.management (preserving hostname and annotations) so it matches all-in-one/values.yaml and will apply correctly when copied.
♻️ Duplicate comments (4)
docs/am-pattern-2-all-in-one_GW/README.md (1)
198-198:⚠️ Potential issue | 🔴 CriticalGateway API support claim contradicts chart implementation.
The documentation states "The Helm chart uses Gateway API by default," but the chart templates only create standard Ingress resources (kind: Ingress), not Gateway API resources like HTTPRoute, BackendTLSPolicy, or GatewayClass. This makes the documented Gateway API configuration path (lines 257-286) non-functional.
To resolve this mismatch, either:
- Update the chart templates to actually create Gateway API resources when
kubernetes.gatewayAPI.enabled: true, or- Clarify in the documentation that users must manually create Gateway API resources (HTTPRoute, BackendTLSPolicy) and that the chart only configures the backend services.
Also applies to: 257-286
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-2-all-in-one_GW/README.md` at line 198, The doc claims the Helm chart uses Gateway API by default but the chart templates only render kind: Ingress resources; either implement Gateway API resource templates guarded by the kubernetes.gatewayAPI.enabled flag (create HTTPRoute, BackendTLSPolicy, and GatewayClass manifests and conditionally render them in the chart instead of Ingress when kubernetes.gatewayAPI.enabled is true) or update the README text and the section referenced (lines ~257-286) to state that the chart does not create Gateway API objects and that users must manually create HTTPRoute/BackendTLSPolicy/GatewayClass resources while the chart only configures backend Services/Deployments.docs/am-pattern-4-ACP_TM_GW_KM/README.md (1)
231-233:⚠️ Potential issue | 🔴 CriticalGateway install command uses the wrong chart name.
Line 232 uses
wso2/wso2-gw; this should bewso2/wso2am-gwto match the chart naming used across this repo.🛠️ Proposed doc fix
- helm install apim-gw wso2/wso2-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim + helm install apim-gw wso2/wso2am-gw --version 4.6.0-1 -f default_gw_values.yaml -n apim🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md` around lines 231 - 233, The helm install command in the README uses the wrong chart name: update the command that currently references "wso2/wso2-gw" (the helm install apim-gw ... line) to use "wso2/wso2am-gw" instead so it matches the chart naming convention used across the repo; ensure the rest of the command (release name apim-gw, chart version, -f default_gw_values.yaml, -n apim) remains unchanged.docs/am-pattern-5-all-in-one_GW_KM/README.md (1)
43-43:⚠️ Potential issue | 🟡 MinorPattern description is still misleading for Pattern 5 scope.
Line 43 still describes full TM/GW separation from control plane, which doesn’t match this pattern’s all-in-one + GW/KM extraction framing used elsewhere in this doc.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-5-all-in-one_GW_KM/README.md` at line 43, Update the Pattern 5 summary sentence ("This document provides comprehensive instructions for deploying WSO2 API Manager in a distributed Kubernetes environment using Helm charts, with a focus on separating the Traffic Manager and Gateway from the Control Plane.") to accurately reflect this doc's scope (all-in-one with GW/KM extraction) rather than full TM/GW separation; edit that sentence to mention "all-in-one deployment with optional Gateway and Key Manager extraction" and ensure consistency with the rest of the README and headings that describe the all-in-one + GW/KM extraction pattern.docs/am-pattern-0-all-in-one/README.md (1)
108-176:⚠️ Potential issue | 🔴 CriticalGateway API value paths in this section don’t match the all-in-one chart implementation.
This section documents
kubernetes.gatewayAPI.*/backendTLSPolicy.*and default Gateway API behavior, but the provided chart template evidence for all-in-one renders only KubernetesIngressviakubernetes.ingress.*. Following this block will lead to non-functional configuration.🛠️ Suggested direction
- By default, the charts are configured to use the Envoy Gateway... + Use `kubernetes.ingress.*` values for this chart’s built-in routing resources. - kubernetes: - gatewayAPI: - ... - backendTLSPolicy: - ... + kubernetes: + ingress: + enabled: true + tlsSecret: "my-tls-secret" + management: + hostname: "am.wso2.com" + gateway: + hostname: "gw.wso2.com"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-0-all-in-one/README.md` around lines 108 - 176, The docs describe and show values for kubernetes.gatewayAPI.* and backendTLSPolicy.* but the all-in-one chart only exposes kubernetes.ingress.*; update the README to match the chart by replacing Gateway API examples and YAML snippets with the actual keys (e.g., use kubernetes.ingress.enabled, kubernetes.ingress.tlsSecret, kubernetes.ingress.hostname, and any ingress-specific CA/TLS options) or explicitly state that Gateway API/Envoy is not supported by this chart and provide the correct NGINX Ingress configuration examples; update references to backendTLSPolicy to the corresponding ingress TLS/CA settings used by the chart so users applying the shown values will get a functional deployment.
🧹 Nitpick comments (6)
docs/am-pattern-2-all-in-one_GW/README.md (1)
530-541: Minor clarification: "Gateway resource" vs "Gateway API".Line 531 says "Obtain the external IP (ADDRESS) of the Gateway API," which could be clearer as "Obtain the external IP (ADDRESS) of the Gateway resource" to distinguish between the Gateway API (the specification) and a Gateway resource (the Kubernetes object).
Otherwise, the dual-path guidance for obtaining external IPs from either Gateway or Ingress resources is clear and helpful.
📝 Suggested clarification
-Obtain the external IP (ADDRESS) of the Gateway API, by listing down the Gateway resources. +Obtain the external IP (ADDRESS) of the Gateway resource, by listing down Gateway resources.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-2-all-in-one_GW/README.md` around lines 530 - 541, Change the wording that currently reads "Obtain the external IP (ADDRESS) of the Gateway API" to explicitly say "Obtain the external IP (ADDRESS) of the Gateway resource" so readers understand you mean the Kubernetes Gateway object (not the API/spec); update the adjacent sentence that references the Ingress path to keep parallel phrasing, and ensure the kubectl examples ("kubectl get gateway -n <NAMESPACE>" and "kubectl get ing -n <NAMESPACE>") remain as-is for clarity.docs/am-pattern-3-ACP_TM_GW/README.md (5)
495-516: Add examples showing actual service names based on the naming convention.The placeholders
<ACP_SERVICE_NAME>,<TM_SERVICE_NAME>, etc., are used throughout but users may not understand how to derive the actual values. While the Helm naming convention is mentioned at line 227, concrete examples would help.💡 Suggested addition
Consider adding a note in each configuration section explaining the service naming pattern with an example:
```yaml km: # -- Key manager service name if default Resident KM is used serviceUrl: "<ACP_SERVICE_NAME>" servicePort: 9443
Note: The service name follows the pattern
<RELEASE_NAME>-wso2am-control-plane-service.For example, if you installed the ACP with
helm install apim-acp ..., the service name would beapim-acp-wso2am-control-plane-service.Similar notes could be added for TM and GW configurations. </details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/am-pattern-3-ACP_TM_GW/README.mdaround lines 495 - 516, Add concrete
service-name examples and a brief note about the Helm naming convention next to
the km and eventhub blocks: explain that the placeholder <ACP_SERVICE_NAME> maps
to the Helm service name pattern (e.g.,
"<RELEASE_NAME>-wso2am-control-plane-service") and show a short example using a
sample release name (e.g., apim-acp) so readers can derive the actual names;
also add analogous notes for TM and GW sections referencing their placeholders
(<TM_SERVICE_NAME>, <GW_SERVICE_NAME>) and the corresponding Helm service-name
pattern so users can replace placeholders with real service names.</details> --- `237-242`: **Clarify TLS secret usage for Gateway API vs Ingress.** The section states "If you are using the Gateway API, make sure to reference this secret in the TLS configuration for the listeners of your Gateway manifest" (line 241), but the actual mechanism differs significantly between the two approaches: - For Gateway API: The secret is referenced in the **Gateway resource manifest** (not in Helm values) - For Ingress: The secret name is set in the **Helm values** via `kubernetes.ingress.tlsSecret` This distinction could be clearer to prevent users from incorrectly configuring TLS. <details> <summary>📝 Suggested clarification</summary> ```diff -If you are using the Gateway API, make sure to reference this secret in the TLS configuration for the listeners of your Gateway manifest. -If you are using the NGINX Ingress Controller, ensure that the `tlsSecret` field is set to the name of the secret you created. +**For Gateway API:** +Reference this secret in the `certificateRefs` field of your Gateway resource manifest's TLS listeners (see sample-gateway.yaml). + +**For NGINX Ingress Controller:** +Set `kubernetes.ingress.tlsSecret: "my-tls-secret"` in your Helm values.yaml file.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-3-ACP_TM_GW/README.md` around lines 237 - 242, Update the TLS instructions to clearly distinguish usage for Gateway API vs Ingress: state that for Gateway API the TLS secret must be referenced directly in the Gateway resource manifest (e.g., in the listeners' tls config of your Gateway manifest) while for the NGINX Ingress Controller the secret name must be provided in Helm values under kubernetes.ingress.tlsSecret; mention these exact places (Gateway manifest listeners and kubernetes.ingress.tlsSecret) so users know where to set the secret for each approach.
258-265: Consider clarifying the distinction between sample and custom manifests.While the maintainer has explained that the sample manifest (
docs/assets/sample-gateway.yaml) is for quick-start and<your-gateway-manifest>represents a custom file, the current wording could still cause confusion. The phrase "You can create and apply the created Gateway" is somewhat redundant.📝 Suggested clarification
- Create and apply a Gateway and GatewayClass. A sample manifest is provided in [docs/assets/sample-gateway.yaml](docs/assets/sample-gateway.yaml). - You can create and apply the created Gateway and GatewayClass resources by running the following command: + To use the sample manifest or apply your own custom Gateway manifest, run: ```bash - kubectl apply -f <your-gateway-manifest> -n <namespace> + kubectl apply -f <path-to-your-gateway-manifest> -n <namespace>
- For quick-start, you can use the provided sample:
- kubectl apply -f docs/assets/sample-gateway.yaml -n
</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/am-pattern-3-ACP_TM_GW/README.mdaround lines 258 - 265, Update the
README wording to clarify the difference between the provided sample manifest
and a user’s custom manifest: replace the redundant phrase "You can create and
apply the created Gateway" with a clearer sentence that explains
is your custom file and that
docs/assets/sample-gateway.yaml is an optional quick-start sample; explicitly
show both commands (one using and one using
docs/assets/sample-gateway.yaml) so readers know how to apply either file with
kubectl apply -f -n .</details> --- `473-482`: **Clarify the JWKS URL configuration guidance.** The current explanation about "virtual host like `am.wso2.com` that is not globally routable" may confuse users. The key point is that the JWKS URL should use the Kubernetes service name for internal communication, not the external hostname configured in Gateway API or Ingress. <details> <summary>📝 Suggested improvement</summary> ```diff -By default, for the super tenant, the Resident Key Manager's JWKS URL is set to `https://<HOSTNAME>:9443/oauth2/jwks`. If you are using a virtual host like `am.wso2.com` that is not globally routable, this URL will be incorrect. You can configure the correct JWKS URL for the super tenant using the Helm chart as shown below: +By default, for the super tenant, the Resident Key Manager's JWKS URL uses the external hostname. In a Kubernetes deployment, components should use the internal service name for inter-component communication. Configure the JWKS URL to use the ACP service name as shown below:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-3-ACP_TM_GW/README.md` around lines 473 - 482, The README's JWKS URL guidance is confusing; update the text to state that the Helm key wso2.apim.configurations.oauth_config.oauth2JWKSUrl must point to the Kubernetes service DNS name used for internal communication (e.g., use ACP_SERVICE_NAME or full cluster DNS like acp-service.namespace.svc.cluster.local) rather than an externally routed hostname, remove or rephrase the "virtual host... not globally routable" line, and give a clear example showing the service-based URL (https://<ACP_SERVICE_NAME>:9443/oauth2/jwks) and note it is for internal cluster access.
402-402: Provide specific value paths for hostname configuration.The instruction "update them under the Kubernetes Gateway API or Ingress section" is too vague for users unfamiliar with the chart structure.
📝 Proposed clarification
- - If you need to change the hostnames, update them under the Kubernetes Gateway API or Ingress section. + - If you need to change the hostnames: + - For Gateway API: Update `kubernetes.gatewayAPI.management.hostname`, `kubernetes.gatewayAPI.gateway.hostname`, etc. + - For Ingress: Update `kubernetes.ingress.management.hostname`, `kubernetes.ingress.gateway.hostname`, etc.Note: This suggestion assumes Gateway API values will be properly implemented. If they are not currently supported (as flagged in the previous comment), adjust the documentation accordingly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/am-pattern-3-ACP_TM_GW/README.md` at line 402, Replace the vague instruction with explicit value paths showing where to change hostnames: indicate the exact Helm chart values keys to edit (e.g., values.gateway.hosts or values.gateway.hostname for Gateway API and values.ingress.hosts or values.ingress.host for Ingress), give an example key hierarchy (values.gateway.enabled, values.gateway.hosts[]) and note the fallback to values.ingress.* when Gateway API support is not available; ensure the README text references these symbols (values.gateway.hosts, values.gateway.hostname, values.ingress.hosts) and includes a short note that the Gateway API paths should be used only if the chart implements Gateway API support.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/am-pattern-0-all-in-one/README.md`:
- Around line 31-34: The "About this Document" section currently describes a
distributed deployment and separation of Traffic Manager/Gateway, but this file
is for Pattern 0 (all-in-one); update the paragraph under "## About this
Document" to state that the guide covers deploying WSO2 API Manager as an
all-in-one Pattern 0 deployment (single node/control plane with integrated TM
and Gateway) and remove references to distributed Kubernetes or separating TM/GW
from the control plane so the description matches the Pattern 0 intent.
In `@docs/am-pattern-1-all-in-one-HA/README.md`:
- Around line 174-175: The README references non-existent Helm values
kubernetes.gatewayAPI.*; update the documentation (lines around the Envoy/NGINX
section) to use the actual chart keys kubernetes.ingress.* and
kubernetes.route.* as exposed by the all-in-one chart (values.yaml), or
alternatively change the chart to expose kubernetes.gatewayAPI.*—ensure the
README toggling instructions and examples match the exact value names
(kubernetes.ingress.* / kubernetes.route.*) used by the chart so users' Helm
overrides are applied correctly.
- Line 202: The link "A sample manifest is provided in
[docs/assets/sample-gateway.yaml](docs/assets/sample-gateway.yaml)." in
README.md is using a nested relative path that resolves incorrectly; update that
link to point to the correct location (e.g. change the target to
../assets/sample-gateway.yaml or to an absolute repo-root path
/docs/assets/sample-gateway.yaml) so the sample-gateway.yaml reference resolves
from docs/am-pattern-1-all-in-one-HA/README.md; locate the exact link text in
the file and replace the URL accordingly.
- Line 210: The doc incorrectly states that TLS listeners are defined on the
"GatewayClass"; update the sentence to say that listeners (and TLS listener
configuration referencing the TLS secret) are defined on the Gateway resource,
not GatewayClass, and ensure the text references the Gateway resource,
Gateway.listeners, and the TLS secret being referenced by the Gateway listener
for TLS termination.
- Around line 35-40: The "About this Document" section incorrectly describes a
distributed topology; update the README heading content so it accurately
reflects Pattern 1's all-in-one/single-node runtime: replace references to
"distributed Kubernetes environment" and "separating the Traffic Manager and
Gateway from the Control Plane" with wording that states this guide covers the
all-in-one Pattern 1 deployment and its minimal configuration, and ensure the
"Minimal Configuration" bullet and subsequent scope lines consistently describe
single-node/all-in-one topology rather than distributed separation.
In `@docs/am-pattern-3-ACP_TM_GW/README.md`:
- Around line 279-306: The README shows a kubernetes.gatewayAPI.* example that
doesn't exist in the chart (no .Values.kubernetes.gatewayAPI references); either
implement Gateway API support in the Helm templates to honor
.Values.kubernetes.gatewayAPI (add template logic and values.yaml entries for
gatewayAPI, management, gateway, websocket, websub, backendTLSPolicy,
backendTrafficPolicy) or remove/replace the example with the actual supported
keys (kubernetes.ingress.* and kubernetes.route.*) so docs match the chart;
update the README content block to reflect the chosen approach and ensure the
example keys exactly match the values.yaml/template symbols used by the chart.
- Around line 267-268: The docs currently reference a non-existent
docs/assets/sample-gateway.yaml and misuse Gateway API terminology; either add
the missing sample-gateway.yaml at docs/assets/ with a complete Gateway
manifest, or update the README to replace those file references with an inline
Gateway YAML example that shows a Gateway resource (not GatewayClass) and a
listener with TLS certificateRefs pointing to a placeholder TLS secret name
(e.g., certificateRefs: name: <TLS_SECRET_NAME>) so readers can update it;
ensure all occurrences of "Gateway class" -> "Gateway resource" and "listeners
of the Gateway class" -> "listeners of the Gateway resource" are corrected and
reference the Gateway manifest or inline YAML accordingly.
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 194-202: The README’s fenced bash code block that starts with the
helm install command (the block containing "helm install envoy-gateway
oci://docker.io/envoyproxy/gateway-helm ... --create-namespace") is not closed;
add a closing triple-backtick (```) immediately after that command line to
terminate the code fence so the subsequent text ("Apply the sample Gateway
manifest...") is rendered as normal prose.
- Line 284: Edit the sentence that mentions where listeners are defined: replace
"Gateway class" with "Gateway" so it correctly states that the TLS secret must
be referenced in the listeners of the Gateway (i.e., Gateway.spec.listeners) in
your Gateway manifest rather than on GatewayClass; update the text near the
gateway manifest and TLS secret references to mention "Gateway" and
"Gateway.spec.listeners" explicitly to avoid confusion.
In `@docs/am-pattern-5-all-in-one_GW_KM/README.md`:
- Around line 185-193: The "Minimal Configuration" section's bash block isn't
closed: add a closing triple-backtick (```) immediately after the helm install
command block (after the line ending with --create-namespace) to terminate the
code fence so the subsequent text "Apply the sample Gateway manifest..." renders
correctly; look for the open bash fence around the helm install command in
README.md and insert the closing ``` on its own line following that command.
- Around line 269-270: The sentence currently says the TLS secret should be
referenced "in the listeners of the Gateway class" — update it to state that the
TLS secret must be referenced in the listeners on the Gateway resource (i.e.,
Gateway.spec.listeners) rather than on GatewayClass; use phrasing like "the TLS
secret created above should be referenced in the listeners on the Gateway
resource (Gateway.spec.listeners) for TLS termination" and ensure references to
GatewayClass are not used for listeners.
---
Outside diff comments:
In `@docs/am-pattern-1-all-in-one-HA/README.md`:
- Around line 268-275: The README ingress example uses ingress.controlPlane
which doesn't match the chart's values key ingress.management; update the
snippet in README.md to use ingress.management (preserving hostname and
annotations) so it matches all-in-one/values.yaml and will apply correctly when
copied.
---
Duplicate comments:
In `@docs/am-pattern-0-all-in-one/README.md`:
- Around line 108-176: The docs describe and show values for
kubernetes.gatewayAPI.* and backendTLSPolicy.* but the all-in-one chart only
exposes kubernetes.ingress.*; update the README to match the chart by replacing
Gateway API examples and YAML snippets with the actual keys (e.g., use
kubernetes.ingress.enabled, kubernetes.ingress.tlsSecret,
kubernetes.ingress.hostname, and any ingress-specific CA/TLS options) or
explicitly state that Gateway API/Envoy is not supported by this chart and
provide the correct NGINX Ingress configuration examples; update references to
backendTLSPolicy to the corresponding ingress TLS/CA settings used by the chart
so users applying the shown values will get a functional deployment.
In `@docs/am-pattern-2-all-in-one_GW/README.md`:
- Line 198: The doc claims the Helm chart uses Gateway API by default but the
chart templates only render kind: Ingress resources; either implement Gateway
API resource templates guarded by the kubernetes.gatewayAPI.enabled flag (create
HTTPRoute, BackendTLSPolicy, and GatewayClass manifests and conditionally render
them in the chart instead of Ingress when kubernetes.gatewayAPI.enabled is true)
or update the README text and the section referenced (lines ~257-286) to state
that the chart does not create Gateway API objects and that users must manually
create HTTPRoute/BackendTLSPolicy/GatewayClass resources while the chart only
configures backend Services/Deployments.
In `@docs/am-pattern-4-ACP_TM_GW_KM/README.md`:
- Around line 231-233: The helm install command in the README uses the wrong
chart name: update the command that currently references "wso2/wso2-gw" (the
helm install apim-gw ... line) to use "wso2/wso2am-gw" instead so it matches the
chart naming convention used across the repo; ensure the rest of the command
(release name apim-gw, chart version, -f default_gw_values.yaml, -n apim)
remains unchanged.
In `@docs/am-pattern-5-all-in-one_GW_KM/README.md`:
- Line 43: Update the Pattern 5 summary sentence ("This document provides
comprehensive instructions for deploying WSO2 API Manager in a distributed
Kubernetes environment using Helm charts, with a focus on separating the Traffic
Manager and Gateway from the Control Plane.") to accurately reflect this doc's
scope (all-in-one with GW/KM extraction) rather than full TM/GW separation; edit
that sentence to mention "all-in-one deployment with optional Gateway and Key
Manager extraction" and ensure consistency with the rest of the README and
headings that describe the all-in-one + GW/KM extraction pattern.
---
Nitpick comments:
In `@docs/am-pattern-2-all-in-one_GW/README.md`:
- Around line 530-541: Change the wording that currently reads "Obtain the
external IP (ADDRESS) of the Gateway API" to explicitly say "Obtain the external
IP (ADDRESS) of the Gateway resource" so readers understand you mean the
Kubernetes Gateway object (not the API/spec); update the adjacent sentence that
references the Ingress path to keep parallel phrasing, and ensure the kubectl
examples ("kubectl get gateway -n <NAMESPACE>" and "kubectl get ing -n
<NAMESPACE>") remain as-is for clarity.
In `@docs/am-pattern-3-ACP_TM_GW/README.md`:
- Around line 495-516: Add concrete service-name examples and a brief note about
the Helm naming convention next to the km and eventhub blocks: explain that the
placeholder <ACP_SERVICE_NAME> maps to the Helm service name pattern (e.g.,
"<RELEASE_NAME>-wso2am-control-plane-service") and show a short example using a
sample release name (e.g., apim-acp) so readers can derive the actual names;
also add analogous notes for TM and GW sections referencing their placeholders
(<TM_SERVICE_NAME>, <GW_SERVICE_NAME>) and the corresponding Helm service-name
pattern so users can replace placeholders with real service names.
- Around line 237-242: Update the TLS instructions to clearly distinguish usage
for Gateway API vs Ingress: state that for Gateway API the TLS secret must be
referenced directly in the Gateway resource manifest (e.g., in the listeners'
tls config of your Gateway manifest) while for the NGINX Ingress Controller the
secret name must be provided in Helm values under kubernetes.ingress.tlsSecret;
mention these exact places (Gateway manifest listeners and
kubernetes.ingress.tlsSecret) so users know where to set the secret for each
approach.
- Around line 258-265: Update the README wording to clarify the difference
between the provided sample manifest and a user’s custom manifest: replace the
redundant phrase "You can create and apply the created Gateway" with a clearer
sentence that explains <path-to-your-gateway-manifest> is your custom file and
that docs/assets/sample-gateway.yaml is an optional quick-start sample;
explicitly show both commands (one using <path-to-your-gateway-manifest> and one
using docs/assets/sample-gateway.yaml) so readers know how to apply either file
with kubectl apply -f <manifest> -n <namespace>.
- Around line 473-482: The README's JWKS URL guidance is confusing; update the
text to state that the Helm key
wso2.apim.configurations.oauth_config.oauth2JWKSUrl must point to the Kubernetes
service DNS name used for internal communication (e.g., use ACP_SERVICE_NAME or
full cluster DNS like acp-service.namespace.svc.cluster.local) rather than an
externally routed hostname, remove or rephrase the "virtual host... not globally
routable" line, and give a clear example showing the service-based URL
(https://<ACP_SERVICE_NAME>:9443/oauth2/jwks) and note it is for internal
cluster access.
- Line 402: Replace the vague instruction with explicit value paths showing
where to change hostnames: indicate the exact Helm chart values keys to edit
(e.g., values.gateway.hosts or values.gateway.hostname for Gateway API and
values.ingress.hosts or values.ingress.host for Ingress), give an example key
hierarchy (values.gateway.enabled, values.gateway.hosts[]) and note the fallback
to values.ingress.* when Gateway API support is not available; ensure the README
text references these symbols (values.gateway.hosts, values.gateway.hostname,
values.ingress.hosts) and includes a short note that the Gateway API paths
should be used only if the chart implements Gateway API support.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9880c1b4-4704-4ac7-9f28-4d9ddf9e2306
📒 Files selected for processing (6)
docs/am-pattern-0-all-in-one/README.mddocs/am-pattern-1-all-in-one-HA/README.mddocs/am-pattern-2-all-in-one_GW/README.mddocs/am-pattern-3-ACP_TM_GW/README.mddocs/am-pattern-4-ACP_TM_GW_KM/README.mddocs/am-pattern-5-all-in-one_GW_KM/README.md
DDH13
force-pushed
the
main.gateway-api.docs.2
branch
from
dbdd3b9 to
22eff8f
Compare
RakhithaRR
approved these changes
Mar 16, 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.
This pull request updates the documentation to recommend Envoy Gateway (Gateway API) as the default and preferred traffic routing solution for WSO2 API Manager Helm deployments, deprecating the NGINX Ingress Controller option. The changes provide clearer, step-by-step instructions for both minimal and advanced configurations, and update terminology, examples, and YAML values to reflect this shift. It also clarifies how to configure TLS, DNS, and hostnames for both routing solutions.
Routing Controller Modernization:
Documentation Improvements & Clarity:
Terminology and Usage Updates:
Default Values and Minor Fixes:
highAvailabilitysetting indefault_values.yamlfromtruetofalsefor clarity in minimal configuration.These updates ensure that users are guided toward the modern, supported routing approach while maintaining backward compatibility and clear migration paths.