1. Docs
  2. Changes and releases
  3. AI Agents

AI Agents

  • AI Agents agent-platform v4.76.0

    Added

    • The model pods export their traces to the platform’s OTLP collector: the kserve-config-llm-tracing preset follows global.observability.traces.otlp, and <release>-model-serving-otlp-egress opens its endpoint (giantswarm/giantswarm#36711, giantswarm/kserve#99). The llm-d controller emits no spans; vLLM and the endpoint picker of an LLMInferenceService whose spec carries tracing export to the preset’s endpoint, which upstream hardcodes to http://otel-collector:4317. kserve-runtime-configs.kserve.llmisvcConfigs.tracing.exporterEndpoint and its podLabels tenant label are auto, written from the global endpoint and tenant by agent-platform.shape.otlp; an explicit value wins, and an http/protobuf global protocol fails the render while the endpoint is auto (gRPC only). The connectivity chart opens the model pods’ egress, both flavours, to modelServing.networkPolicy.otlpEndpoint (auto), where the meta chart writes the preset’s resolved endpoint. Nothing exports until a service carries tracing: {} (README “The model pods’ traces”). Pin first: components.kserve-runtime-configs.versionRange is 0.6.x and examples/customer-bom.yaml pins 0.6.0, the release that opens the key; verify-serving-slice and verify-model-serving-policies hold the resolution, the guards and the egress.
  • AI Agents agent-platform v4.75.1

    Changed

    • Substrate’s metrics stay on the scrape path: substrate.otel.metrics.enabled is false (giantswarm/giantswarm#36711). With the PodMonitors on and the OTLP endpoint set, every ateapi, atelet, atenet-router and atecontroller series reached Mimir twice, scraped (ate_actor_crashes_total, job ate-system/ate-api-server) and pushed (ate_actor_crashes, job ateapi), about 6,300 series on gazelle. The value renders OTEL_METRICS_EXPORTER=none, which the Go components honor from giantswarm/substrate#82 on and ignore before it; traces and logs keep exporting. The worker pods’ ateom exports through the WorkerPool’s environment and keeps pushing. make verify-substrate-otlp asserts the forwarded value.
  • AI Agents agent-platform v4.75.0

    Changed

    • One OTLP collector for the whole platform: global.observability.traces.otlp (endpoint, protocol, the new tenant, headers) sets every exporter’s destination (giantswarm/giantswarm#36711). The meta chart writes it into each component key that is now auto by default: kagent.otel.{tracing,logging}.exporter.otlp.endpoint and .tracing.exporter.otlp.protocol, OTEL_EXPORTER_OTLP_HEADERS in kagent.controller.env and kagent.harness.env, muster.muster.observability.otel.{endpoint,protocol,headers}, klausGateway.observability.{otlpEndpoint,otlpHeaders}, substrate.otel.endpoint, the tenant label in substrate.podLabels and gateway.parameters.podLabels, and the two OTLP entries of gateway.parameters.dataPlaneEnv (in both charts). A component key set to anything else wins. The defaults are the kube-system otlp-gateway on 4317 over gRPC with the giantswarm tenant, so every component renders as before. The tenant goes out as X-Scope-OrgID from kagent, muster and klaus-gateway, and as the observability.giantswarm.io/tenant pod label on Substrate and the data plane. kagent.otel.{tracing,logging}.exporter.otlp.insecure is auto too, false for an https:// endpoint. An empty endpoint exports nothing and turns kagent’s auto exporters and Substrate’s signals off; an X-Scope-OrgID in headers that differs from tenant fails the render, and so does protocol: http/protobuf while klaus-gateway, Substrate or kagent’s log exporter (gRPC only) would take the endpoint. The connectivity chart’s OTLP egress rules follow each exporter’s resolved endpoint. In the connectivity chart a dataPlaneEnv entry now wins over global.observability.traces.otlp (it used to lose), and make verify-otlp-global asserts the derivation and the egress rules.
  • AI Agents agent-platform v4.74.3

    Fixed

    • The kagent controller’s metrics port and atenet-egress’s ext-proc 9090 are admitted from the cluster entity, so their monitors scrape (giantswarm/giantswarm#36711). The controller’s ingress policy opened the API port 8083 only, so the scrape of kagent.controller.metrics.bindAddress (:8080) was dropped and kagent-controller-metrics reported up=0 on every installation; the rule renders while kagent.controller.metrics.enabled is true, in both flavours, and never opens the API port. substrate-atenet-egress opened 15020 only, so the ext-proc’s 9090 target was down the same way. make verify-kagent-netpol asserts both.
  • AI Agents agent-platform v4.74.2

    Fixed

    • The models Gateway’s data plane is an internet-facing load balancer on AWS (giantswarm/agent-platform#690). On a workload cluster with the AWS Load Balancer Controller the data plane’s Service carried no scheme, so it became an internal NLB and external-dns published the models host with private addresses. modelServing.modelsGateway.service.annotations renders on the Gateway’s infrastructure.annotations, which the Service inherits, with and without external-dns; the default is service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing, and an explicit value replaces it (internal for a private models host). Other providers ignore the annotation. make verify-serving-slice holds the default and the override.
  • AI Agents agent-platform v4.74.1

    Fixed

    • model-manager reaches the workload clusters’ API servers its kserve backends target (giantswarm/agent-platform#687). A kserve backend cluster-manager registers calls a workload cluster’s apiserver as the caller, but model-manager’s egress policy had no rule for it, so under the cilium flavour list_backends timed out dialing the cluster’s API server and every tool naming that backend with it. modelManager.networkPolicy.workloadClusters (fqdns, cidrs, ports, the shape of cluster-manager’s) follows clusterManager.networkPolicy.workloadClusters when empty, the default, and replaces it as a whole when set. It renders in both flavours with a kserve backend (static, or cluster-manager on): names and blocks in the cilium flavour, the blocks or every public destination on the ports in the kubernetes flavour. make verify-cluster-manager holds it.
  • AI Agents muster v5.32.6

    Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.32.5...v5.32.6

  • AI Agents muster v5.32.5

    Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.32.4...v5.32.5

  • AI Agents agent-platform v4.74.0

    Changed

    • The CloudNativePG operator comes from gsoci: the chart from oci://gsoci.azurecr.io/giantswarm/cloudnative-pg/charts, the image from gsoci.azurecr.io/giantswarm/cloudnative-pg (giantswarm/agent-platform#580). components.cloudnative-pg.repository names the gsoci copy of the upstream chart, which retagger keeps under its upstream path from the 0.29 line on with the digests preserved (giantswarm/retagger#1244), and cloudnative-pg.image.repository names the operator image’s gsoci copy, the upstream image at the same digest and signed with the Giant Swarm identity. The tag stays the chart’s appVersion. The 0.29.x range and the cloudnative-pg: values shape are unchanged, and the Giant Swarm wrapper chart is not used: it wraps an older operator line behind a different values shape. The last ghcr.io chart source leaves make verify-images’ PENDING list. An installation with the component on sees the operator Deployment roll once to the gsoci image name, and CloudNativePG then restarts every instance pod once, since the pods’ bootstrap init container names the operator image: a single-instance cluster is unavailable for the seconds its pod takes to restart. A management cluster runs the operator as its own app and keeps this component off, so nothing rolls there.
  • AI Agents agent-platform v4.73.2

    Fixed

    • Switching the serving slice off, or uninstalling a release that carries it, no longer leaves kserve-runtime-configs UninstallFailed or its configs terminating (giantswarm/agent-platform#527). The llm-d controller (kserve-llmisvc-resources) puts serving.kserve.io/llmisvcconfig-finalizer on every well-known LLMInferenceServiceConfig, is the only thing that clears it, and its webhook denies every delete of such a config while it runs; Helm deleted both child HelmReleases in one pass, so the configs’ uninstall was denied, or the configs were left terminating for the next slice to adopt and lose (ConfigNotFound). A hook Job <release>-serving-teardown (weight -2, the helm image, as <release>-hooks, with the engine and without it) now removes them in order: the controller’s release, waited for until its Deployment and the webhook configuration are gone; the configs of kserve-runtime-configs, deleted through the CRD’s storage version with the finalizer taken off; then the configs’ release. It runs at pre-delete while both components are on, and at pre-upgrade when components.kserve-runtime-configs goes off while its live HelmRelease is the release’s (a lookup). Switching kserve-runtime-configs off while kserve-llmisvc-resources stays on is refused with the reason. Not with gitops.target.kubeConfig: cluster-manager tears its slices down in this order itself. make verify-serving-teardown asserts the renders and runs the script against a stub kubectl. README “Uninstalling”.