1. Docs
  2. Changes and releases

Changes and Releases

Updates on Giant Swarm workload cluster releases, apps, UI improvements and documentation changes.

  • CAPA releases releases aws-31.2.0

    Mitigates the “Dirty Frag” Linux kernel vulnerabilities (esp4/esp6, rxrpc) that could allow local privilege escalation and container escape on affected nodes.

    Changes compared to v31.1.2

    Components

    • cluster-aws from v3.6.2 to v3.8.0
    • cluster from v2.5.1 to v2.6.1
    • Flatcar from v4152.2.3 to v4593.2.1
    • os-tooling from v1.26.1 to v1.31.0

    cluster-aws v3.6.2…v3.8.0

    Changed

    • Support newer Flatcar versions which require a larger root volume size. For ease of migration, enforce at least 15 GB even if a smaller, explicit size is specified in chart values.

    cluster v2.5.1…v2.6.1

    Added

    • Add enabled flag to providerIntegration.workers.kubeadmConfig to disable the rendering of the KubeadmConfig resource.
    • containerd: Add flag to enable SELinux.

    Changed

    • Values: Fix schema. (#580)
  • CAPA releases releases aws-32.3.0

    Mitigates the “Dirty Frag” Linux kernel vulnerabilities (esp4/esp6, rxrpc) that could allow local privilege escalation and container escape on affected nodes.

    Changes compared to v32.2.0

    Components

    • cluster-aws from v5.4.0 to v5.5.0
    • Flatcar from v4230.2.4 to v4593.2.1
    • os-tooling from v1.26.2 to v1.31.0

    cluster-aws v5.4.0…v5.5.0

    Changed

    • Support newer Flatcar versions which require a larger root volume size. For ease of migration, enforce at least 15 GB even if a smaller, explicit size is specified in chart values.
  • CAPA releases releases aws-33.3.0

    Mitigates the “Dirty Frag” Linux kernel vulnerabilities (esp4/esp6, rxrpc) that could allow local privilege escalation and container escape on affected nodes.

    Changes compared to v33.2.0

    Components

    • cluster-aws from v6.4.4 to v6.5.0
    • Flatcar from v4459.2.1 to v4593.2.1
    • os-tooling from v1.26.2 to v1.31.0

    cluster-aws v6.4.4…v6.5.0

    Changed

    • Support newer Flatcar versions which require a larger root volume size. For ease of migration, enforce at least 15 GB even if a smaller, explicit size is specified in chart values.
  • CAPA releases releases aws-34.3.0

    Mitigates the “Dirty Frag” Linux kernel vulnerabilities (esp4/esp6, rxrpc) that could allow local privilege escalation and container escape on affected nodes.

    Changes compared to v34.2.0

    Components

    • cluster-aws from v7.6.1 to v7.7.1
    • Flatcar from v4459.2.4 to v4593.2.1
    • os-tooling from v1.28.0 to v1.31.0

    cluster-aws v7.6.1…v7.7.1

    Changed

    • Support newer Flatcar versions which require a larger root volume size. For ease of migration, enforce at least 15 GB even if a smaller, explicit size is specified in chart values.
  • CAPV releases releases vsphere-34.3.0

    Mitigates the “Dirty Frag” Linux kernel vulnerabilities (esp4/esp6, rxrpc) that could allow local privilege escalation and container escape on affected nodes.

    Changes compared to v34.2.0

    Components

    • Flatcar from v4459.2.4 to v4593.2.1
    • os-tooling from v1.28.0 to v1.31.0
  • CAPVCD releases releases cloud-director-34.3.0

    Mitigates the “Dirty Frag” Linux kernel vulnerabilities (esp4/esp6, rxrpc) that could allow local privilege escalation and container escape on affected nodes.

    Changes compared to v34.2.0

    Components

    • Flatcar from v4459.2.4 to v4593.2.1
    • os-tooling from v1.28.0 to v1.31.0
  • CAPZ releases releases azure-34.3.0

    Mitigates the “Dirty Frag” Linux kernel vulnerabilities (esp4/esp6, rxrpc) that could allow local privilege escalation and container escape on affected nodes.

    Changes compared to v34.2.0

    Components

    • Flatcar from v4459.2.4 to v4593.2.1
    • os-tooling from v1.28.0 to v1.31.0
  • Fleet Management kubectl-gs v5.5.0

    Added

    • login: support direct OIDC authentication for workload clusters (Kubernetes structured authentication). The appropriate workload-cluster authentication mode is now selected automatically based on the cluster’s configuration.
  • Developer Portal backstage v0.130.0

    Added

    • PagerDuty integration: “Who is on call” entity card, catalog processor that auto-annotates entities with PagerDuty IDs, and MCP action to resolve PagerDuty IDs from catalog entities.

    Changed

    • Backstage liveness/readiness probe timings are now configurable via .Values.probes.{liveness,readiness} (initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold) and the default timeoutSeconds is raised from the k8s implicit 1 to 5. The HTTP path/port stay fixed (/.backstage/health/v1/{liveness,readiness} on port). The k8s default 1s is tight against the chart’s 500m CPU limit: event-loop stalls during plugin startup, GC, or DB reconnects regularly miss the deadline and surface as Unhealthy: ... context deadline exceeded events even though the pod keeps serving traffic (observed on the BWI Backstage Deployment on spidertron, 2026-05-11). See ./docs/releases/v0.130.0-changelog.md for more information.
  • Developer Portal backstage v0.129.3

    Fixed

    • Stabilise the AI chat transport across React renders. useChatSetup constructed a fresh AssistantChatTransport on every render and handed it to useChatRuntime; when its identity changed mid-stream (e.g. as a side effect of a state update triggered by streamed reasoning-delta / tool-input-delta events), the runtime tore down the in-flight chat fetch with TypeError: network error. Envoy logged the symptom as response_flags: DC (downstream remote disconnect) against a healthy Backstage upstream while the SSE stream summary was sawFinish=false, last event tool-input-delta, surfacing in the UI as a “Network error” banner even though no real network outage occurred. The transport is now memoised on the resolved API URL and the stable getHeaders / debugFetch callbacks, so a single transport lives for the component’s lifetime.
    • AI chat instrumentation: observe the caller’s AbortSignal and log abort events with the reason inline (ABORT signaled by client at <ms> -- reason: <name>: <message>). Stream-outcome lines now annotate aborted streams with [client-aborted at Nms reason="..."] so a “Network error” banner can be classified as a deliberate client cancel (transport rebuild, unmount, manual stop) versus a real proxy / network failure (no abort signal fired, raw stream error). Read errors that fired after the caller aborted are now logged as console.warn (“cancelled by client AbortSignal”) rather than console.error (“STREAM READ FAILED”), reserving the latter for the genuine pre-finish, non-aborted failure mode.

    See ./docs/releases/v0.129.3-changelog.md for more information.