Repository navigation
Converge on a single ingress topology: agentgateway in front of muster, everywhere #252
Description
Problem
ingress.mode offers three topologies:
agentgateway-muster(the default since v4.114.0) — clients reach agentgateway on/mcp, which fronts muster.muster-direct(deprecated) — clients reach muster directly; agentgateway is not deployed.agentgateway-direct(deprecated, render-blocked) — requires a DCR-capable IdP.
Three modes triple the guard/template/test/docs surface. There should be one topology: agentgateway in front of muster, everywhere.
Proposed solution
Make agentgateway-muster the only supported topology:
- Enable agentgateway and flip the default to
agentgateway-muster; roll it out across fleet installations. Done: feat: agentgateway in front of muster is the default topology #810, released in v4.114.0. - Remove
muster-directandagentgateway-direct: values keys, render guards, conditional templates,verify-modesmatrix entries, and README/docs sections. - Let
agent-platform-standalone's curate run pick up the simplification.
Removing the values keys is a breaking chart change: step 2 needs an explicitly approved major release.
Acceptance criteria
- All installations route MCP traffic through agentgateway in front of muster
-
ingress.modeis gone (or reduced to a single, non-configurable topology) - Guards, templates, and CI mode-matrix reduced to the single topology
- README and public docs describe one topology only
-
agent-platform-standaloneregenerated accordingly
Activity
teemow commentedon Oct 5, 2026
Step 1 is done (written by an agent on Timo's behalf).
ingress.mode: agentgateway-muster,components.agentgateway.enabled: trueandagent-platform-mcps.agentgateway.viaMuster: true. A release without muster (a serving or runtime slice) renders no ingress data plane, whatever the mode.muster-directandagentgateway-directare deprecated.agentgateway-muster, so the default flip changes no installation's values. Capability reconcile dry runs across every installation with the agent platform show no ingress-related change. v4.114.0 is Ready on the test and production installations./mcprouted through agentgateway to muster.initializegoes through agentgateway's MCP route and gets muster's 401 withresource_metadata.Remaining: steps 2 and 3. Removing
muster-direct,agentgateway-directand the mode switch is a breaking change and needs an approved major release, so this issue stays open for it.teemow commentedon Oct 6, 2026
Step 1's remaining lab proofs ran on v4.114.0 (written by an agent on Timo's behalf).
The local lab runs agent-platform 4.114.0 from the released chart (no local chart), with the default
ingress.mode: agentgateway-muster. Its Anthropic credential is now in place, which was the only reason both proofs stopped before.agents-test: passes (6 of 6, exit 0). An agent is created through muster as the signed-in person, becomes Ready on the kagent Harness and answers a turn. It is then updated, its skills refreshed and deleted. A viewer's create is refused by the apiserver. The agent-manager ServiceAccount holds no RBAC beyond discovery.
toolsets-test: the toolset and agent steps all pass. The steps:
preset:read-only,preset:noneand header errors.preset:noneagent ("pong").The run then stops at its last check: a fresh id_token of the same person, one that never signed in, also resolves the signed-in server's tools. That is the muster regression tracked in Forwarded-token sign-ins reach every id_token of the person since 5.34.13 muster#1397. It does not depend on the ingress topology.
During the runs, agentgateway's access log shows every
/mcprequest on the muster route answered 200 or 202.This completes step 1, and its acceptance criterion stays checked. The issue stays open for steps 2 and 3: removing
muster-direct,agentgateway-directand the mode switch (a breaking change that needs an approved major release), then regeneratingagent-platform-standalone.