Migrate Talos configmanager to alpha.2 multi-document config API (KubeNetworkConfig / KubeAPIServerConfig)

[devantler]

🤖 Generated by the Daily AI Assistant

Problem

Dependabot PRs #5765 (siderolabs/talos/pkg/machinery) and #5766 (siderolabs/talos) bump Talos 1.14.0-alpha.1 → 1.14.0-alpha.2, and the build fails: alpha.2 removed Network() and APIServer() from the config.ClusterConfig interface.

pkg/fsutil/configmanager/talos/configs.go:539,543,608,612: cp.Cluster().Network undefined (ClusterConfig has no field or method Network)
pkg/fsutil/configmanager/talos/version.go:132:              cluster.APIServer undefined  (ClusterConfig has no field or method APIServer)

Per the Talos v1.14.0-alpha.2 changelog, this is a deliberate move to the multi-document config model:

• .cluster.network deprecated → KubeNetworkConfig document (Flannel via KubeFlannelCNIConfig)
• .cluster.apiServer deprecated → KubeAPIServerConfig (+ KubeAdmissionControlConfig, KubeAuditPolicyConfig, …) documents

The old monolithic-config accessors are gone from the interface, so the two configmanager reads (CNI name, PodCIDRs, APIServer presence) must be re-sourced from the new documents.

Affected reads

Site	Current call	Needs
configs.go:543	cp.Cluster().Network().CNI()	CNI name from KubeNetworkConfig
configs.go:612	cp.Cluster().Network().PodCIDRs()	Pod CIDRs from KubeNetworkConfig
version.go:132	cluster.APIServer()	apiserver settings from KubeAPIServerConfig

Proposed direction

Migrate the Talos configmanager to read CNI/PodCIDRs via the KubeNetworkConfig document and apiserver settings via KubeAPIServerConfig, obtained through the provider's document API. Keep a compatibility path if we still generate v1alpha1-style config anywhere. Update configs_test.go/version_test.go fixtures to the multi-document shape.

Notes / rough size

• M — localized to pkg/fsutil/configmanager/talos + its tests, but the config-shape change ripples through the fixtures.
• alpha.2 is a moving pre-release; these documents may still change before stable v1.14.0. Consider whether to migrate now or hold the pin at alpha.1 until 1.14.0 stabilises (product call). Filing this so the two Dependabot PRs are tracked rather than sitting silently red.

Blocks: #5765, #5766

[devantler]

🤖 Generated by the Daily AI Assistant

Root-cause update — the bump is coupled to the node image (E2E-proven)

Prepared the configmanager migration on branch claude/talos-alpha2-configmanager (draft #5775): reads CNI / pod-CIDRs / apiserver-image via the new K8sNetworkConfig / K8sFlannelCNIConfig / K8sAPIServerConfig accessors. Unit tests, lint, build all green.

But the E2E system tests fail deterministically (10/10 Talos-create jobs), and this is not a flake:

• Every Talos cluster create fails to boot: [talos] task setupSharedFilesystems (5/8): failed: invalid argument → service[apid](Failed) → bootstrap failed (apid never comes up). Retried 3×, same each time.
• The same suite is fully green on the alpha.1 baseline (feat(validate): wire native CEL-rule validation into workload validate #5773, same CI infra, same node image).

Why: ksail pins the Talos node image separately in pkg/fsutil/configmanager/talos/Dockerfile (ghcr.io/siderolabs/talos:v1.13.5), independent of the siderolabs/talos Go module. Bumping the machinery module to alpha.2 changes the generated machine-config format, which the stable v1.13.5 node rejects at the filesystem-setup boot phase. The module and the node image are coupled and must move together.

Recommendation

Hold the Talos 1.14 bump until v1.14.0 stable ships, then bump the machinery module and the node image (DefaultTalosImage) together in one PR. Making #5775 green today would mean shipping a moving 1.14 alpha as ksail's default local node image — a stability regression I don't think is warranted for a pre-release.

Consequences:

• chore(deps): Bump github.com/siderolabs/talos/pkg/machinery from 1.14.0-alpha.1 to 1.14.0-alpha.2 #5765 / chore(deps): Bump github.com/siderolabs/talos from 1.14.0-alpha.1 to 1.14.0-alpha.2 #5766 (Dependabot alpha.2 bumps) will keep failing until then — they're tracked here, not silently red.
• fix(talos): migrate configmanager to alpha.2 multi-document config API #5775 stays a draft carrying the prepared migration; the alpha.2 API may still shift before stable, so the code may need a refresh when v1.14.0 lands.

Verified alpha.2 node image exists (ghcr.io/siderolabs/talos:v1.14.0-alpha.2@sha256:b0a4e619…) — the node-image bump is a one-line Dockerfile change whenever we decide to go.