Changes and Releases
Updates on Giant Swarm workload cluster releases, apps, UI improvements and documentation changes.
Changed
Fixed
- (deps) Drop the replace directives so go install works in #388 by @teemow
- (deps) Update module github.com/giantswarm/klaus-oci to v0.0.80 in #386 by @renovate[bot]
- Ignore CVE-2026-108859 until 2026-11-12, no HTTP handler in #390 by @teemow
- (deps) Update module github.com/mark3labs/mcp-go to v1.3.0 in #394 by @renovate[bot]
Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.5.4...v0.5.5
Added
- (credprovider) Accept Substrate’s actor JWT as the bound person’s bearer in #1573 by @teemow
Full Changelog: https://github.com/giantswarm/muster/compare/v5.44.2...v5.45.0
Added
- (ui-react) BusyDialog gates every dismiss path while busy by @teemow — No visible change: dialogs that work for a while, such as New session, Rename session, Create cluster and Delete cluster, share one way of staying open while busy, against Escape, a click outside, the close button and
Cancel.
Development and CI/CD
Full Changelog: https://github.com/giantswarm/backstage/compare/v3.9.5...v3.10.0
Changed
Fixed
- (workspaces) Refuse workspaces without the agents at render time in #1119 by @teemow
Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.146.0...v4.146.1
Changed
components.substrate.versionRange and components.substrate-crds.versionRange are >=1.14.0 <1.15.0 (were >=1.13.0 <1.14.0), the kagent WorkerPool’s worker image follows to ateom-gvisor:1.14.0, the customer BOM pins Substrate 1.14.0, and substrate.credentialProvider.additionalProviders routes google-access-token.k8s.io to the credential provider plugin (giantswarm/giantswarm#38547). Substrate 1.14.0’s bundled Kubernetes credential provider serves k8s.io alone (giantswarm/substrate#455); the Google access token a Vertex AI ModelConfig’s actor needs comes from components.google-access-token-credential-provider, deployed since 4.141.0, which the egress gateway now reaches for that class. Vertex AI ModelConfigs and their Secrets are unchanged.- One source of truth for the component version floors (giantswarm/agent-platform#1102).
components.<name>.versionRange in values.yaml is the one place a floor is declared: tests/floors.py reads the ranges and floors from it, and the checks that named a floor (verify-presets’ muster, verify-meta’s agentgateway and BOM, verify-components’ ranges, Substrate pin and release-candidate filters, verify-cluster-manager, verify-workspace-manager) ask it instead; a feature floor a check holds a range to stays a minimum (floors.py floor <name> --min). The customer BOM pins every component with a >= floor at that floor: make golden-update writes the pins, make verify-meta fails on one that differs. A floor move is one edit of values.yaml plus make golden-update. The BOM’s agent-manager pin moves from 2.1.0 to 2.3.0, the floor of its range.
Removed
ingress.mode: agentgateway-direct is gone (giantswarm/agent-platform#252). The mode never rendered: its guard failed every install for want of a DCR-capable IdP. The connectivity chart now refuses it as an unknown mode (must be one of: agentgateway-muster, muster-direct); its viaMuster: false guard, the meta chart’s unused copies of the ingress guard and the mode’s values comments go with it. No installation renders differently. make verify-modes asserts the refusal.
Fixed
- A server that refuses the stored grant on connect answers its sign-in link, not a 401. A session marked signed in to an OAuth server but without a live connection to it (after a restart, or once the pooled connection was retired) opens one on its next tool call; when the server refused the stored token on that handshake, every call failed with
failed to initialize on-demand client ... 401 while muster auth status kept showing the server connected. The call now answers the server’s auth_required challenge with its sign-in link, as a 401 during a call already did: the refused grant is dropped, the session is no longer marked signed in to the server, and core_auth_login issues the sign-in. muster auth login --force --server <name> signs out of a server the session reads connected and signs in to it again; without --force the command says so instead of claiming the server needs no authentication. (#1574) - A
core_auth_login that starts no OAuth flow no longer spends the person’s authentication attempts. Every call was charged to the per-user rate limit (10 attempts a minute) before muster looked at the session, so a client checking a server’s connection with core_auth_login (the portal does before it acts for the person) used up the attempts with answers like “already authenticated” and the next real sign-in was refused with “Rate limit exceeded … Remaining attempts: 0”. An attempt is now charged only when the answer needs an OAuth flow, a held grant reused or a new challenge; answers that start none (already authenticated, no authentication needed, a deactivated or SSO-managed server) are free. The limit itself is unchanged. (#1567)
