AI Agents

  • Added

    • Awaiting Session: a per-session server’s state says whether it works. An MCPServer whose callers bring their own identity (auth.forwardToken, auth.tokenExchange) holds no connection of its own and, with no session connected, read Auth Required – the same state as a server waiting for a person to sign in through muster, and the same state whether every exchange succeeded or none could. Such a server now reads Awaiting Session (service state awaiting_session, Normal event MCPServerAwaitingSession) wherever it read Auth Required before: after the probe, after the last session’s connection is lost, after an automatic recovery reached it; Auth Required keeps its one meaning. A tokenExchange server verifies its client credentials Secret at start and is Failed with the Secret named while it is missing, retried with the reconnect backoff so a Secret that arrives later heals it. Every per-user exchange the aggregator performs reaches the server’s state: a failure every caller shares (the credentials Secret, invalid_client, a token endpoint that does not answer or answers 5xx, an unknown connector) puts the server in Failed with the exchange error as lastError, and the next successful exchange, a restart or a spec change returns it to Awaiting Session; a failure of the caller’s own token stays that session’s. The reconciler writes a Ready condition for every server whose reason names the state (AwaitingSession, Connected, AuthRequired, Suspended, …) or the class of an exchange failure (TokenExchangeCredentials, TokenExchangeEndpoint, TokenExchangeConnector) and whose message explains it – for Awaiting Session the mechanism, the token endpoint and connector, and when the last exchange succeeded. muster list mcpserver, core_service_status, the CRDs of both charts and the reference docs carry the state; core_service_start and core_service_restart on such a server say what it waits for instead of pointing at a sign-in that does not exist. The scenario oauth-sso-token-exchange-state pins the states through a real RFC 8693 exchange against the harness’s authorization server. (#1300)
  • Changed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.27.10...v5.27.11

  • Fixed

    • Agentgateway controller at the line’s 2.0.0 under its nested name

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.23.1...v3.23.2

  • Changed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.23...v0.1.24

  • Added

    • The three upstream lines at their decoupled releases — kagent 1.0.0, Substrate 1.0.0, agentgateway 2.0.0 in full (#608) in #609 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.48.2...v4.49.0

  • Fixed

    • model-serving: gemma-4-31b serves 8k context on the 48 GB card — vLLM needs 9.5 GiB of KV cache for 32k next to 31.7 GiB of weights and has 7.3, and named 8640 tokens as the ceiling; 32k returns with an fp8 KV cache once that is proven on the L40S (#591).
  • Fixed

    • model-serving: gemma-4-31b serves 32k context and qwen3-6-35b-a3b 16k on the 48 GB card — the 64k the first shipped with needs 12 GiB of KV cache next to 31.7 GiB of weights and vLLM refused to start (estimated maximum model length is 8624); the fit check passed it (giantswarm/model-manager#149) (#591).
  • Added

    • The kagent line’s and the Substrate line’s charts from gsoci (#580) in #592 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.47.1...v4.48.0

  • Fixed

    • model-serving: every preset served from a model image sets USER, LOGNAME and TORCHINDUCTOR_CACHE_DIR — the predictor runs as the modelcar uid, which the runtime image’s passwd does not know, and vLLM’s import died in torch’s inductor cache-dir lookup (getpwuid(1010)) on every one of the new presets (#591).
  • Fixed

    • A remote MCPServer whose endpoint answers the initialize with a 4xx is retried. A forwardToken server registered while its backend did not serve the path yet – a rollout in progress, the previous pod answering 404 – failed its registration probe with server returned 4xx for initialize POST, likely a legacy SSE server, read Failed and was never re-probed: the answer was not classified as a connection failure, so no retry was scheduled, and the sessions connecting later with their own token do not touch the CR’s state. The server stayed Failed (and MusterMCPServerFailed fired after 20 minutes) although the backend had been serving the path since seconds after the registration. Such an answer now enters the reconnect schedule like a refused connection or a 5xx: retried with the same backoff, the MCPServerFailed event and status.lastFailureHTTPStatus naming the status mcp-go dropped (endpoint answered HTTP 404, next retry in 30s at ...), and the server settles on its own once the path answers – in Auth Required for a server connected per session, Connected otherwise. The state rules of a per-session server (Failed only while the endpoint does not answer, Auth Required until the first session connects, Connected from then on, a later session’s failure never the server’s state) are documented in the CRD reference. (#1295)