Repository navigation
[Automated] Draft docs (agentgateway): ui: show Client Setup in XDS mode (+3 related) - #1238
Conversation
…ode (+3 related) Signed-off-by: GitHub Action <action@github.com>
Deploying agentproxy with
|
| Latest commit: |
54f578f
|
| Status: | ⚡️ Build in progress... |
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Kristin Brown <kristin.brown@solo.io>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Signed-off-by: Kristin Brown <kristin.brown@solo.io>
…eway-3634-plus3 Signed-off-by: Kristin Brown <kristin.brown@solo.io>
|
|
||
| The agentgateway UI is a built-in web interface that runs on port 15000 of the `agentgateway-proxy` pod. In Kubernetes mode, the UI is **read-only**. It reflects the configuration that the agentgateway controller pushes to the proxy over xDS, the protocol that the control plane uses to deliver configuration to the proxy. | ||
|
|
||
| {{< version include-if="1.0.x,1.1.x,1.2.x,1.3.x,1.4.x,1.5.x,1.6.x,2.2.x" >}} |
There was a problem hiding this comment.
Do the older versions really need the part about following the issue for client setup? That will show that the issue is now done and might confuse them. I would just remove the line.
Follow agentgateway/agentgateway#2989 for the Client Setup enhancement.
There was a problem hiding this comment.
Good point, removed. I also removed the same line from the older-version note in llm-client-setup-index-k8s.md.
| Whether the UI can save the changes that you make depends on your storage mode. In the binary and Docker installations, the UI writes to your configuration file by default. In the Helm installation, the ConfigMap is read-only and a save fails unless you switch the chart to database mode. For more information, see [Configuration storage]({{< link-hextra path="/documentation/setup/storage/" >}}). | ||
|
|
||
| {{< version exclude-if="1.0.x,1.1.x,1.2.x,1.3.x,1.4.x,1.5.x,1.6.x,2.2.x" >}} | ||
| In **Settings** > **UI**, choose the public gateway that serves the UI and configure policies that protect the UI. If the UI is already served on a public gateway, the UI asks you to confirm before you save a different gateway or **None**. If you opened the UI through the gateway that you remove, you lose access to the page. With **None**, the UI is served only on the admin interface, which listens on `localhost` by default and might not be reachable from outside a container. In **Settings** > **Observability**, configure tracing and access logs for all traffic. |
There was a problem hiding this comment.
I am not sure what these two paragraphs are meant to do in this section that is about trying the UI and links out to two guides. Are they supposed to come back here and read this?
Also the first sentence makes this sound like a task topic to secure the UI
In Settings > UI, choose the public gateway that serves the UI and configure policies that protect the UI.
But then the rest of it, I am not sure, it starts jumping around to different pages and does not seem connected to the first sentence, nor to the content that has come before it in this section.
There was a problem hiding this comment.
Agreed, it did not fit in "Try out the UI." A section that lists what is in the Settings pages would be a UI tour, not a task, so I removed it. Changing the UI gateway from the UI is now a short task, Change the UI gateway in the UI, on the Serve the UI on a gateway page. It covers the lock-out risk and that choosing None removes the ui section, including its policies.
| {{< version exclude-if="1.0.x,1.1.x,1.2.x,1.3.x,1.4.x,1.5.x,1.6.x,2.2.x" >}} | ||
| In **Settings** > **UI**, choose the public gateway that serves the UI and configure policies that protect the UI. If the UI is already served on a public gateway, the UI asks you to confirm before you save a different gateway or **None**. If you opened the UI through the gateway that you remove, you lose access to the page. With **None**, the UI is served only on the admin interface, which listens on `localhost` by default and might not be reachable from outside a container. In **Settings** > **Observability**, configure tracing and access logs for all traffic. | ||
|
|
||
| The UI checks a change before it writes the configuration file, so a save that is not valid fails with an error and the file does not change. If you edit the file outside the UI and agentgateway rejects the reload, the UI shows a **Configuration reload failed** banner. The banner means that agentgateway still runs the previous valid configuration. The UI and `/api/config/effective` show the file on disk, including the change that agentgateway rejected. Fix the file and save it again to retry the reload. |
There was a problem hiding this comment.
This paragraph about writing to config file seems more related to the paragraph that is before the previous paragraph that starts
Whether the UI can save the changes that you make depends on your storage mode.
I am wondering if these two paragraphs should be combined together to be a section about UI storage? or is that duplicated elsewhere on this page or a different UI page?
There was a problem hiding this comment.
Yes, combined. Both paragraphs are now in a new Save changes from the UI section. I did not find this content on the other UI pages.
Signed-off-by: Kristin Brown <kristin.brown@solo.io>
3 participants
agentgateway/agentgateway#3634 — ui: show Client Setup in XDS mode
Docs versions:
standalone/mainWhat changes for users: The agentgateway UI now exposes Client Setup in XDS mode, uses dump models there, waits for a gateway URL before generating snippets, and derives the standalone URL from the browser origin when the UI and LLM traffic share a gateway. The UI also reports failed configuration reloads, shows the running version, and asks for confirmation before changing the gateway that serves the UI.
What the docs now say: The Launch the UI page now describes the main-only Client Setup and configuration-state behavior: when users must enter the gateway URL, which models appear from the config dump, what the reload-failure banner means, and why changing the UI gateway needs confirmation.
Not verified: No cluster or UI was run; the documentation is unrun.
How
agentgateway-3634was drafted, and what was not verifiedPlan, and what changed it
assets/agw-docs/standalone/setup/ui/launch.mdis the reusable body forcontent/docs/standalone/main/documentation/setup/ui/launch-ui.mdand already owns Client Setup, save behavior, and next steps.content/docs/standalone/main/documentation/llm/playground.mdis about sending test LLM requests, not wiring clients or managing UI settings.assets/agw-docs/standalone/setup/ui/launch.md, and left the LLM playground, setup UI index, expose, gateway, secure, configuration index, and reference pages unchanged.Why a documentation change is necessary
The #3634 dossier says Client Setup is now available in XDS mode, uses public concrete models and virtual models from
/config_dump, excludes internal models, and requires users to enter the externally reachable gateway URL before snippets appear. The existing Launch the UI page already documented Client Setup as a standalone UI workflow, but it did not explain XDS behavior or the new URL gate. The #3692, #3733, #3772, and #3807 dossiers add UI-visible behavior that a user can see while following the same page: reload-failure state, the sidebar version, confirmation before changing the UI gateway, and the corrected base URL source.What changed on disk
assets/agw-docs/standalone/setup/ui/launch.md: Added gated main-only guidance for the UI version/sidebar, UI gateway change confirmation, reload-failure banner, Client Setup URL behavior, and XDS model selection.How to verify this change
/ui/llm/client-setupin file-backed mode with an LLM gateway configured. The Gateway base URL field is pre-populated, and if the UI is served from the same gateway, the value uses the browser origin./ui/llm/client-setupin XDS mode with a config dump that contains public concrete, virtual, internal, and wildcard models. The LLM navigation includes Client Setup, the model selector includes public concrete and virtual models, internal models are absent, and snippets appear only after Gateway base URL is set./api/runtimereportsconfigReload.synchronized: false, and/api/config/effectivecontinues to show the saved file that needs to be fixed.What was not verified
The configuration was not applied to a cluster, and the UI was not run. The dossier provided UI tests for the behavior, but this CI sandbox did not execute them.
How the pages were chosen (triage report)
Feature clusters
These pull requests document one feature between them:
content/docs/standalone/main/documentation/llm/playground.md, the only page a code-path rule names for one of them, so separate pull requests would conflictKept apart on purpose. Merging wrongly produces a guide that documents two things and explains neither, so these are reported for a person to merge rather than grouped automatically:
content/docs/standalone/main/documentation/llm/playground.mdas a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land therecontent/docs/standalone/main/documentation/llm/playground.mdas a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land therecontent/docs/standalone/main/documentation/llm/playground.mdas a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land therecontent/docs/standalone/main/documentation/llm/playground.mdas a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land therecontent/docs/standalone/main/documentation/llm/playground.mdas a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land therecontent/docs/standalone/main/documentation/llm/playground.mdas a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land therecontent/docs/standalone/main/documentation/llm/playground.mdas a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land therecontent/docs/standalone/main/documentation/llm/playground.mdas a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land thereThese clusters look incomplete. Each names a pull request this run never saw, so documenting the cluster as it stands may describe half a feature — the classic failure is a guide telling a reader to set a field that a later change gave a default. Read the absent pull request before drafting:
Draft a documentation change
agentgateway/agentgateway#3634 — ui: show Client Setup in XDS mode
agentgateway/websiteagentgateway/agentgateway#3733 — ui: add version on sidebar
agentgateway/websiteagentgateway/agentgateway#3772 — ui: add confirmation when changing where we serve it
agentgateway/websiteNew configuration: no page mentions it yet
agentgateway/agentgateway#3692 — fix: report the running config from /api/config/effective
agentgateway/website/api/runtimehad no reload state, so the UI silently implied the on-disk configuration was running.crates/agentgateway/src/lib.rscrates/agentgateway/src/state_manager.rsRelease notes not placed. These need a person; the run could not resolve where they go:
area: <label>first line and a one-line bullet in its noteDraft branch:
pr-tracker-draft-agentgateway-3634-plus3