feat: add support for v1.14 config documents

[clementnuss]

closes #127

[clementnuss]

this is still very much a draft. I just let GLM 5.3 try its best; code quality is likely not up to standards 😅

[clementnuss]

I think we should try to provide some more templating attributes for nodes: something like .Node.RuntimeData.TalosVersion for example, so people can handle the transition to machine-less configs as smoothly as possible

[oscrx]

Ran topf 0.6.0-rc.0 / Talos 1.14.0-rc.2 against a 4-node IPv6 cluster (3 control planes + 1 worker), migrating every v1alpha1 field to documents. Two topf issues, one upstream note.

1. UnattendedInstallConfig.provisioning is never populated, so stock output doesn't validate.

Empty patches/ dir, minimal topf.yaml:

$ topf render -o out
Wrote machine config for cp1 to out/cp1.yaml

$ talosctl validate -c out/cp1.yaml -m metal
1 error occurred:
	* UnattendedInstallConfig: provisioning.volumeSelector.match is required

Rendered:

kind: UnattendedInstallConfig
installer:
    image: factory.talos.dev/metal-installer/…:v1.14.0-rc.2
provisioning: {}

talosctl gen config fills it in and validates:

provisioning:
    diskSelector:
        match: disk.dev_path == "/dev/sda"
    wipe: false

Related: the document defaults wipe to true, but topf 0.5 emitted machine.install.wipe: false. It only bites on an unattended reinstall, but it's a silent flip on upgrade unless users pin it.

2. render never validates its own output — it exits 0 on the invalid config above. Validating there would have surfaced #1 immediately.

Upstream, not topf: the error says provisioning.volumeSelector.match, but the field is provisioning.diskSelector — there's no volumeSelector in the document.

Rest of the migration was clean. .Node.Data was enough to template a per-node NIC for DHCPv6Config, FWIW re: your .Node.RuntimeData comment.

[clementnuss]

really cool feedback, thanks. I will try to fix the 2 issues you mention later this week.

as for .Node.RuntimeData, the use case is handling clusters with heterogeneous node versions but a single config repository/folder. we will add a template function to decide whether a certain file should render based on the talos version. might not be useful for a home lab but as we run clusters in production with >100 nodes, we need a way to be able to keep running topf apply there for the time period where nodes get upgraded.

but overall really happy that you managed to upgrade everything without more hiccups, that's a good validation of our config model: just forwarding the upstream config documents is the only way forward.

[TheoBassaw]

Migration worked perfectly on my part. No issue to report at the moment.

[clementnuss]

was more effort than anticipated but that's done! here's an example config migration: clementnuss/k8s-gitops@ba92108