Fixed
- (model-serving) Qwen3-8-flash-next-nvfp4 memory limit 118Gi — B12X keeps the weights as mlocked process memory the cgroup charges in #567 by @teemow
Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.38.2...v4.38.3
Updates on Giant Swarm workload cluster releases, apps, UI improvements and documentation changes.
Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.38.2...v4.38.3
Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.38.1...v4.38.2
mcpCapi and mcpPrometheus (oidc.staticClients.mcpCapi, oidc.staticClients.mcpPrometheus) with the shape and rules of mcpKubernetes: clientID, redirectURI, trustedPeers, and exactly one of clientSecret and clientSecretRef: {name, key}; both are trusted peers of dex-k8s-authenticator. Values under these keys were accepted by the schema and ignored by the templates before: an installation that carries them gets the two clients with this version, and one that carries a clientID without a secret fails the render naming the client. Installations without them render unchanged.Full Changelog: https://github.com/giantswarm/muster/compare/v5.27.1...v5.27.2
secretRef: {name, key} in an extraStaticClients entry, clientSecretRef: {name, key} in the pre-defined clients (gitopsui, muster, mcpKubernetes, dexK8SAuthenticator), in place of the inline secret. The chart sets DEX_CLIENT_SECRET_<ID> on the dex container from the referenced key and names it in the client’s secretEnv, so a client is added by a new Secret and a plaintext list entry. Exactly one of the inline secret and the reference per client: both, or neither on a client that is not public, fails the render naming the client. Inline clients render unchanged.clientID but no secret (gitopsui, muster, mcpKubernetes) fails the render naming the client instead of being left out of the configuration silently.Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.38.0...v4.38.1
Full Changelog: https://github.com/giantswarm/backstage/compare/v2.29.1...v2.30.0
checksum/config annotation with the hash of the rendered dex configuration, so every change to it produces a new ReplicaSet in the same helm upgrade that writes the secret. The Deployment is rendered by the parent chart from the subchart’s template to compute the checksum; its output is unchanged apart from the annotation. Before, the pod kept the configuration it had loaded at startup until something else restarted it.Full Changelog: https://github.com/giantswarm/backstage/compare/v2.29.0...v2.29.1
Full Changelog: https://github.com/giantswarm/backstage/compare/v2.28.1...v2.29.0