fix(talos): three further variant patch layouts are skipped or rejected by the 1.14 migration

[devantler]

🤖 Generated by the Daily AI Engineer

Problem

The Talos 1.14 legacy-patch migration (#5771, PR #5775) now handles the standard ksail-generated patch layouts and the three variant gaps from #6167. A Codex review at head 43a0c4e3 surfaced three further non-standard patch layouts that were valid before 1.14 — because configpatcher.LoadPatch accepted them and all patches were applied together — but are now skipped or hard-rejected by the migration.

Each is verified against the code on #5775's branch. None is a blocker for #5775 itself (the standard and #6167 layouts migrate correctly); these are the next tier of variant handling.

Affected audience & impact

Operators pinning an existing cluster to Talos 1.14 whose patch set was hand-written or grouped differently from ksail's generated form. Impact ranges from a silently un-migrated patch (surfacing later at config generation/apply) to an aborted load that forces manual file surgery before they can pin 1.14.

The three gaps

1. RFC6902 (JSON-patch) list patches skip migration entirely. decodeLegacyKubernetesDocuments treats a YAML list as non-map, so migrateLegacyKubernetesPatch returns the original content unchanged. These are valid configpatcher.LoadPatch inputs and the codebase already accounts for RFC-6902 patches elsewhere. An operator who disabled the default CNI or set a now-denied API-server arg in JSON-patch syntax therefore gets neither the 1.14 Flannel-delete conversion nor the new denied-extra-args preflight — the invalid legacy patch surfaces later, at generation/apply, instead of being migrated or rejected up front.

   • Expected: either migrate RFC6902 list patches, or reject them with an explicit, actionable migration-time error — not a silent passthrough.

2. A multi-document API-server patch file hard-fails. Two legacy cluster.apiServer documents with disjoint edits in one file abort with errLegacyAPIServerMultipleDocuments, even though that multi-document strategic-merge layout was accepted pre-1.14 and applied in order. Users who grouped their API-server patches in one file cannot pin 1.14 without manually splitting or merging it.

   • Expected: migrate each document like separate patch files are, or state precisely why merging is unsafe.

3. Split OIDC flags are not resolved across the patch set. fix(talos): migrate non-standard legacy patch layouts (CNI/OIDC-CA/auth extraArgs) #6167 Gap 2 fixed the oidc-ca-file lookup to span the whole patch set, but oidcConfig still reads oidc-issuer-url / oidc-client-id only from the patch being migrated. A pre-1.14-valid split layout therefore fails: the issuer-only patch errors as missing the client ID, and the client-only patch is rejected as an orphaned oidc-* arg.

   • Expected: resolve the OIDC flags across the full patch set, consistent with Gap 2. The decoded patch-set context is already threaded through as values.patchSetDocuments, so the data is available — this is the smallest of the three.

Acceptance criteria

• Gap A: an RFC6902 list patch is either migrated or rejected with an actionable error; test both.
• Gap B: a multi-document API-server patch file migrates each document (or fails with a precise, justified reason); test.
• Gap C: a split issuer/client-id OIDC layout migrates without error; test.

Size

~S each (independently shippable). Gap C is smallest and reuses the Gap 2 machinery.

Deferred from #5775; findings by the Codex reviewer at head 43a0c4e3. The P1 authorizer-ordering finding from the same pass was refuted against Talos's ControlPlaneAuthorizationController source (it prepends defaults via slices.Insert at index 0/1 and keys on Type), consistent with the earlier refutation on #5775.

[coderabbitai]

🔗 Related PRs

#5506 - test(autoscaler): cover the #5219 baseline-propagation routing dispatcher [closed]
#5519 - feat(bootstrap): plan k3s install configs from a cluster topology [closed]
#5525 - fix(autoscaler): grant Deployment/ResourceQuota RBAC unconditionally [closed]
#5533 - feat(workload): add --schema-location for catalog-absent CRDs [closed]
#5541 - feat(validator): warn when a Talos install-image patch duplicates extensions [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!