valkey component ships deploymentStrategy: Recreate. The single pod owns an RWO PVC, so under RollingUpdate every values or chart change deadlocked the rollout: with one replica maxUnavailable is 0, the new pod waited on Multi-Attach for a volume the old pod held, and Helm timed out after 5 minutes. An installation that pinned valkey.valkey.deploymentStrategy keeps its own value. The store is a cache, so the restart gap between the two pods costs nothing.Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.0.2...v3.0.3
kyvernoPolicies.volumeTypesPolicyName (restrict-volume-types) and kyvernoPolicies.volumeTypesRuleNames (restricted-volumes, autogen-restricted-volumes) keys it targets, in both charts. The connectivity chart renders it only when postgres.vector.extensionImage.reference is set, the one configuration where a CNPG pod mounts an image volume, which is not in that policy’s allowed types. Without the exception admission rejects every instance pod, the Cluster reaches no active instance, and the kagent controller crashloops on its pgvector check. The exception matches on the cnpg.io/cluster label of postgres.clusterName, so it covers that Cluster’s pods and the operator’s bootstrap Jobs only. No installation needs to act unless its cluster names those policies differently.Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.0.0...v3.0.1
components.<name>.enabled on agent-platform-connectivity, the same key path the meta chart reads. The meta chart forwards the component roster, stripped to enablement, into the values of that release, so the wiring the chart renders for a component agrees with whether the component has a release. Set it directly only when installing agent-platform-connectivity on its own.kyvernoPolicies.enabled (default true) in both charts. Set it to false on a cluster that has no Kyverno: the connectivity chart then renders none of its kyverno.io objects (the two kagent declarative-agent ClusterPolicies, the kagent seccomp PolicyException, the agent-sandbox pod-security ClusterPolicy), which otherwise fail the install on an unknown API group. No installation needs to act. A cluster that enforces restricted PSS through PSA labels instead of Kyverno must set components.agent-sandbox.enabled: false as well, or agentSandbox.podSecurity.enabled: false where nothing enforces restricted PSS; the render now fails with that instruction instead of shipping a controller Deployment with no securityContext.agentgateway component tracks the 2.x chart line, which flattened the upstream keys onto the chart root. The forwarded values block is no longer nested under an agentgateway key. The top-level agentgateway: values block otherwise keeps its shape, so only the toggle moves. examples/customer-bom.yaml pins 2.0.0.agentgateway.enabled, valkey.enabled, mcps.enabled, kagent.enabled, klausGateway.enabled and agentSandbox.enabled. components.<name>.enabled is now the only on/off switch for a component, and every installation that sets one of the old keys must move it — see UPGRADE.md for the key-by-key move. components.<name>.enabled already existed and already won over the old enabledFrom indirection, so a component could be disabled two ways and the two answers could disagree: components.agentgateway.enabled: false with agentgateway.enabled: true rendered no agentgateway release but still rendered that controller’s ListenerSet ClusterRole.components.<name>.enabledFrom, the indirection from a component entry to a per-chart toggle. There is nothing left to point at.enabled would silently turn the component off.mcps: values block. It only ever held the toggle; the chart’s values keep living under agent-platform-mcps:.components.<name>.omitKeys, the keys dropped from a component’s forwarded values block. It exists for a block that holds a key belonging to this umbrella rather than to the component’s chart, where that chart validates values with additionalProperties: false and would reject it.Full Changelog: https://github.com/giantswarm/muster/compare/v5.6.1...v5.6.2
Full Changelog: https://github.com/giantswarm/muster/compare/v5.6.0...v5.6.1
Full Changelog: https://github.com/giantswarm/muster/compare/v5.5.6...v5.6.0
retry block (count, delay, backoff_multiplier) is now rejected at load time, with a message pointing at expected.wait_for_state. It was declared on TestStep and range checked by the loader, and nothing else ever read it — so a step declaring retry got exactly one attempt while reading as if it polled, and TestStepResult.RetryCount (printed by the reporter) was always zero. The three steps in the dex-token-forward scenario that used it to poll for eventually-consistent state — backend registration, the OBO reconnect, and the forwarded-token assertion — were therefore flake-prone in precisely the place their author had covered; they now use wait_for_state, which is the mechanism that works. RetryConfig and RetryCount are removed. A new test asserts that every field of TestStep names the file that acts on it, and fails the build when a field is declared and validated but never honoured — the same class of bug as #1038, one level up from expectation kinds.wait_for_state on an MCP tool step no longer discards a first response that already satisfies the step’s expectations. The polling loop ignored the response its caller had just obtained and judged the step only from the first tick onward, so every such step paid a mandatory poll interval, and a step was failed outright when re-invoking the tool did not return the same answer — reported against the first, passing response, so the output showed a satisfied payload on a failed step. Steps whose invocation is the assertion (a token-forwarding call, anything not idempotent) were the ones at risk. The test_* path already judged the first response; the two now agree, which is the parity TestEveryExpectationKindIsEnforcedOnBothStepKinds exists to defend. dex-token-forward drops from 2.5s to 0.5s as a result.