agent-platform release v4.5.0

Added

• The cut-over of an installation to the kagent API v2 line, in the connectivity chart (giantswarm/agent-platform#346; bumblebee-plans#51 D9, D11). The database: the connectivity chart’s postgres.databases map (introduced with Agent Substrate, giantswarm/agent-platform#342 — one CNPG Database per entry on the existing Cluster, <clusterName>-<key>, owned by the bootstrap role, and a post-install,post-upgrade hook Job <release>-postgres-databases that derives each entry’s connection Secret <clusterName>-<key>-app from the bootstrap Secret <clusterName>-app) gains the shipped entry kagent-v2: spec.name: kagent_v2, the vector extension, databaseReclaimPolicy: retain, rendered while the kagent component is on. Its derived Secret kagent-pg-kagent-v2-app in the kagent namespace is what the kagent API v2 controller mounts (database.postgres.urlFile; the mount examples and ci/test-postgres-values.yaml name it, the fleet template’s secretName follows). The controller refuses the 0.10 schema and no conversation history is migrated, so it starts fresh on kagent_v2; the 0.10 database kagent stays untouched for 30 days and is then dropped — the new postgres.applicationDatabase.ensure: absent renders ensure: absent on its Database object in the ImageVolume extension mode (the chart otherwise re-creates it after a hand DROP), the psql command otherwise (UPGRADE.md). The bootstrap database’s own Database and sessionsDatabase keep their templates. The migration: agentManager.migration (both charts; on by default, rendered when kagent and agent-manager are on) renders a plain Job agent-platform-connectivity-agent-manager-migrate-<8-hex hash of its image, args and environment> in the kagent namespace running agent-manager migrate (dryRun adds --dry-run) from agent-manager’s image at image.tag — the meta chart’s BOM pin for the agent-manager component — as the tenant identity kagent.fluxServiceAccountName (the helper, never the literal), with its inputs as environment (the kagent namespace, the additional managed namespaces, the agent chart’s OCI URL and range, the GitOps namespaces, the platform Harness kagent, GITHUB_TOKEN from githubToken.secretName/key, default kagent-skills-token/token, optional). Deliberately not a Helm hook: a migrate failure must never fail the upgrade that renders the platform Harness, and the meta chart’s new roster key components.<name>.disableWaitForJobs (install/upgrade.disableWaitForJobs: true, set on agent-platform-connectivity) stops helm-controller from waiting on the release’s Jobs — hooks are unaffected. The hash in the name makes a changed spec a new Job (the old-named one is removed) instead of an immutable-template error; an unchanged spec leaves the completed Job in place, so the expand phase runs when 4.0 first renders the Job and the contract phase is a re-run (a clone by hand, or the next upgrade after the Job’s day-long TTL). Its migration-only rights are plain objects too: ONE ClusterRole on customresourcedefinitions confined to the five removed CRDs (agents, sandboxagents, agentharnesses, memories, toolservers of kagent.dev) with get, delete, bound by ONE ClusterRoleBinding — the chart’s only cluster-scoped binding — and a Role + RoleBinding (get, list on helmreleases, ocirepositories) per namespace in gitopsNamespaces (the fleet: flux-giantswarm, where the GitOps-owned agents’ releases live). A network policy in both flavors admits the Job’s egress to DNS, the API server, api.github.com and the agent chart’s registry. The report is the ConfigMap agent-manager-migrate-report in the kagent namespace (written by the command); a failed phase leaves the v1alpha2 objects in place; a FAILED Job stays a day and can be cloned by hand (kubectl create job --from takes CronJob sources only; UPGRADE.md carries the command), or the hooks are re-run with flux reconcile helmrelease --force. An empty tenant identity with the migration on fails the render. The Job and its bindings retire in a later 4.x release. make verify-postgres (verify-postgres-kagent-v2), verify-identity (verify-identity-migration: exactly that one ClusterRoleBinding, none while off) and the new verify-migration (plain Job, stable hash name that changes with the image, the roster key on the connectivity release only) assert it; tests/pick-doc.py selects one object of a render by kind and name. The ATS kind smoke keeps agentManager.migration.enabled: false — the bare smoke serves no live kagent API v2 for migrate to act on; the migration rehearsal is agentlab#143. No 3.x installation is affected: the connectivity chart of this line is bounded below 4.0; the objects render on the 4.0 line, whose cut-over UPGRADE.md describes.