Changed
- (deps) Update gsoci.azurecr.io/giantswarm/agentgateway docker tag to v1.5.0 in #246 by @renovate[bot]
Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.2.2...v3.2.3
Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.2.2...v3.2.3
Full Changelog: https://github.com/giantswarm/klaus/compare/v0.0.311...v0.0.312
Full Changelog: https://github.com/giantswarm/klaus/compare/v0.0.310...v0.0.311
Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.2.48...v0.2.49
Full Changelog: https://github.com/giantswarm/klaus-operator/compare/v0.0.145...v0.0.146
Full Changelog: https://github.com/giantswarm/klaus-oci/compare/v0.0.69...v0.0.70
Full Changelog: https://github.com/giantswarm/muster/compare/v5.7.1...v5.7.2
AgentgatewayParameters renders the Service-type overlay at spec.service.spec.type, the path the CRD declares (an embedded ServiceSpec under spec.service.spec), instead of spec.service.type, which is not in the schema. Until now the overlay never took effect: helm-controller’s client-side apply silently pruned the unknown field, so the agentgateway data-plane Service stayed at the controller-hardcoded LoadBalancer; under Helm 4’s default server-side apply the same field made the install hard-fail (.spec.service.type: field not declared in schema). Visible rollout effect: on installations running an agentgateway-* ingress mode without the chart-owned edge, the data-plane Service now actually becomes gateway.parameters.serviceType (default ClusterIP, the intended state — the front Gateway serves public traffic), which deletes the unintended cloud LoadBalancer that the pruned overlay left behind. Edge-mode installs (gatewayApi.gateway.create: true) keep LoadBalancer via gatewayApi.gateway.serviceType. Fixes #250.Full Changelog: https://github.com/giantswarm/muster/compare/v5.7.0...v5.7.1
validateLegacyToggles, both charts) is coalescing-safe. In a layout where a component block feeds a real Helm dependency (the standalone umbrella copies this helper), Helm coalesces that chart’s own top-level enabled: true default into the block once the dependency is on (klaus-gateway ships one), so the plain hasKey probe could not tell an operator-set value from the chart default and was skipped exactly where it mattered. The guard now reports a legacy key when it is provably the operator’s: always while the component is off, and while it is on when the value is an explicit false — the case where the operator believes the component is off while it runs anyway. A leftover enabled: true under a component that is on is indistinguishable from a coalesced chart default and passes.