Problem
talm upgrade fires the upgrade RPC without comparing the running Talos version against the target parsed from the image tag. If values.yaml::image is older than what the node runs (stale preset default, mistaken edit), talm silently initiates a downgrade. Talos does not support downgrades across minor versions; the result ranges from an A/B rollback to a broken node. The post-upgrade verify only compares running vs target after the fact — a "successful" downgrade passes it (running == target at major.minor), and the write-back then pins the node file to the older image.
Concrete shape of the trap: a project initialized with an old preset has image: ...talos:v1.10.5 in values.yaml, nodes run v1.12.6, and talm upgrade -f nodes/node1.yaml resolves v1.10.5 and would downgrade without any warning.
Proposal
Before invoking the upgrade RPC, read the running version (same COSI reader as the post-upgrade verify) and compare major.minor against the target tag. If the target is older than the running version, block with a hint-bearing error; allow override with an explicit flag (e.g. --allow-downgrade). Skip the guard on --insecure (no authenticated COSI path), mirroring the post-upgrade verify predicate.
Related: #213 (version-skew gates).
Problem
talm upgradefires the upgrade RPC without comparing the running Talos version against the target parsed from the image tag. Ifvalues.yaml::imageis older than what the node runs (stale preset default, mistaken edit), talm silently initiates a downgrade. Talos does not support downgrades across minor versions; the result ranges from an A/B rollback to a broken node. The post-upgrade verify only compares running vs target after the fact — a "successful" downgrade passes it (running == target at major.minor), and the write-back then pins the node file to the older image.Concrete shape of the trap: a project initialized with an old preset has
image: ...talos:v1.10.5in values.yaml, nodes run v1.12.6, andtalm upgrade -f nodes/node1.yamlresolves v1.10.5 and would downgrade without any warning.Proposal
Before invoking the upgrade RPC, read the running version (same COSI reader as the post-upgrade verify) and compare major.minor against the target tag. If the target is older than the running version, block with a hint-bearing error; allow override with an explicit flag (e.g.
--allow-downgrade). Skip the guard on--insecure(no authenticated COSI path), mirroring the post-upgrade verify predicate.Related: #213 (version-skew gates).