AI Agents

  • Added

    • The muster release detects and corrects drift (#287). The muster HelmRelease carries spec.driftDetection.mode: enabled (components.muster.driftDetection), the second release to carry it after kagent: on every reconcile — gitops.interval — helm-controller compares the release manifest with the cluster and re-applies what differs or is missing, as a server-side apply without a Helm revision. On a management cluster that came through the agentic-platform → agent-platform rename the live CiliumNetworkPolicy muster kept the old namespace in its egress selectors while the release manifest named the new one; Helm’s three-way merge patches only what changed between two release manifests, so the object stayed drifted across every upgrade and muster’s egress to Valkey stayed denied. No ignore rule: nothing of the platform edits this release’s objects in place. An installation that sets muster.autoscaling.enabled: true must add one for /spec/replicas on the Deployment (UPGRADE.md). tests/verify-kagent-wiring.py asserts the set of releases that carry drift detection; the ATS smoke edits an object of the muster release and sees it reverted.
  • Fixed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.15...v0.1.16

  • Changed

    • (renovate) Charts/flux-engine/Chart.yaml appVersion follows the Flux Operator image tag in #453 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.15.1...v4.15.2

  • Changed

    • (deps) Update ghcr.io/controlplaneio-fluxcd/flux-operator docker tag to v0.60.0 in #392 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.15.0...v4.15.1

  • Added

    • (meta) Components.vm-manager from gsoci and the giantswarm catalog (>=0.20.0); the guest image is a fetched artifact, no node paths in #452 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.14.0...v4.15.0

  • Fixed

    • postgres.imagePullSecrets and postgres.affinity, declared by both charts and rendered as Cluster.spec.imagePullSecrets and Cluster.spec.affinity on the platform Postgres Cluster (#311, gap 4). affinity is CNPG’s AffinityConfiguration, not a core Kubernetes Affinity: any other key fails the render, a core podAffinity or podAntiAffinity with a message of its own. Both render no field while unset.
    • A network policy for the Backstage app pods, in both flavours, with components.backstage.enabled and networkPolicy.enabled (#311, gap 1). Ingress: the Gateway that serves the portal’s route — the proxy pods of the namespaces the route names as its parents (backstage.parentRefs, else global.gatewayApi.parentRefs), or the agentgateway data plane while the route attaches to it (backstage.parentRefs wins over gatewayApi.gateway.create for the policy as it does for the route) — and the kubelet’s probes, on backstage.port. Egress: DNS, the kube-apiserver, the identity provider, the edge, muster, the portal’s own CNPG cluster on backstage.database.engine: postgresql, and the scaffolder catalog location on backstage.catalogs.version. The egress leg to the edge follows the Gateways the routes the app-config calls attach to (ingress.parentRefs, kagent.controllerRoute.parentRef, modelManager.route.parentRef), not the portal’s own route, and is opened on 443 and 10443: an Envoy Gateway proxy binds the listener’s port plus 10000, so the pod behind a 443 listener listens on 10443.
  • Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.19.9...v5.19.10

  • Fixed

    • The boot pass no longer reports an MCPServer the reconciler registered a moment earlier as a failure (#1222). The orchestrator’s boot pass and the MCPServer reconciler’s first pass run concurrently: for a definition the boot loop had not reached yet, the reconciler found no service and StartService registered it lazily, and when the loop then got there the refused duplicate registration was logged as ERROR Failed to create MCPServer service: <name> ... service <name> already registered – one misleading error per affected server per boot (two of 87 definitions on one installation) for a service that existed and was being started by the caller that registered it. The registry’s duplicate error now wraps services.ErrServiceAlreadyRegistered and the boot pass treats it as a debug-level no-op (MCPServer <name> was registered through StartService while the boot pass ran; that caller starts it); every other error is reported as before and the suspended-server skip is unchanged.
  • Fixed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.14...v0.1.15

  • Fixed

    • mcp-oauth’s metrics reach muster’s metrics endpoint, the token store’s included. The OAuth server’s instrumentation now records through muster’s own OpenTelemetry meter provider (mcp-oauth 1.4.0, instrumentation.Config.MeterProvider), and the Valkey and in-memory token stores share it. Until now mcp-oauth built a Prometheus collector of its own on the default registerer, which the :9464 endpoint – served from a registry of its own – never gathered: not one oauth_* series was ever exported, and the token store was not instrumented at all. Now oauth_http_requests_total, oauth_token_endpoint_failures_total{grant_type,error_code} and the other oauth_* series, storage_operation_total{operation,result} (result is success, error or timeout), the storage_operation_duration_milliseconds histogram and the storage_*_count size gauges are served next to the muster_* series. A Valkey outage shows as storage_operation_total{result="timeout"} and oauth_token_endpoint_failures_total{error_code="temporarily_unavailable"}.