feat: per-node installer image override for platforms the image factory cannot build

[ojsef39]

Problem

topf upgrade cannot handle a node whose installer image is not an image-factory URL. plan() runs the configured machine.install.image through extractSchematicAndVersion:

pattern := `^.*/([a-zA-Z0-9]+):v?(.+)$`

which requires the last path segment to be a schematic ID. A custom image fails that, and since the error is returned from plan(), one unparseable node aborts the run for the entire cluster, including nodes that would have been fine:

ERROR error error="couldn't extract schematic and version from installer image
'ghcr.io/ojsef39/talos-rpi5-installer:v1.13.10': invalid format: expected */<schematic>:v?<version>"

Only upgrade is affected. apply writes the image without parsing it.

Why a custom image

Raspberry Pi 5 is not supported upstream by Talos, so those nodes install a self-built installer image and the factory cannot produce an equivalent. The cluster is mixed: the amd64 nodes use normal factory images and upgrade fine, the two Pi control planes cannot be upgraded by topf at all.

Current state

pkg/config/node.go exposes factory, platform, schematicId, secureboot and talosVersion, and Node.InstallerImage() always composes <factory>/<platform>-installer/<schematic>:v<version>. There is no way to express a fully custom image.

talhelper covered this with talosImageURL, and topf's own migration skill already flags it as unmapped:

| talosImageURL | derive from factory + schematicId + talosVersion | flag if a specific pinned URL must be preserved |

Proposal

A per-node installerImage which, when set, is used verbatim and skips schematic extraction. The upgrade decision could fall back to comparing the node's running Talos version against talosVersion, or simply always treat such a node as needing an upgrade.

Workaround

--nodes-filter to exclude those nodes, then talosctl upgrade --image by hand.

[ojsef39]

Happy to help move this along: I can test against mixed amd64 / Raspberry Pi 5 clusters running Longhorn (one dev, one live), and I'm open to contributing the change myself if you want to sketch the approach you'd prefer.

[sebastian-stephan]

Have you checked: https://factory.talos.dev/?arch=arm64&platform=metal&schematic-id=a636242df247ad4aad2e36d1026d8d4727b716a3061749bd7b19651e548f65e4&target=sbc&version=1.14.0? It seems that Rpi5 is now supported by the factory?

But in general this could be improved. The only reason we parse the schematic from the installer image is to figure out if that node needs to be upgraded or not.

Adding a installerImage to topf.yaml nodes feels a bit off. I was hoping we keep topf.yaml free from anything that can be specified in config patches.

What could work is the following:

1. Check against a regex matching schematic and version, even stricter than now. (the current version is pretty lax).
2. If that fails, fall back to only extracting the version from the image tag.
3. If the schematic couldn't be extracted only consider the version as a "upgrade required" check.

That would also mean, that if you ever build a new version of the custom image with the same talos version (by adding more kernel modules for example), topf would potentially skip it. Not sure if that is ok.