-
Notifications
You must be signed in to change notification settings - Fork 23
feat(upgrade): pre-upgrade guard against downgrades #219
Copy link
Copy link
Open
Labels
area/commandsIssues or PRs related to pkg/commands (CLI subcommands, flag parsing, root detection)Issues or PRs related to pkg/commands (CLI subcommands, flag parsing, root detection)area/upgradeIssues or PRs related to talm upgrade flow (image extraction, post-upgrade verification)Issues or PRs related to talm upgrade flow (image extraction, post-upgrade verification)kind/featureCategorizes issue or PR as related to a new featureCategorizes issue or PR as related to a new feature
Description
Activity
Metadata
Metadata
Assignees
Labels
area/commandsIssues or PRs related to pkg/commands (CLI subcommands, flag parsing, root detection)Issues or PRs related to pkg/commands (CLI subcommands, flag parsing, root detection)area/upgradeIssues or PRs related to talm upgrade flow (image extraction, post-upgrade verification)Issues or PRs related to talm upgrade flow (image extraction, post-upgrade verification)kind/featureCategorizes issue or PR as related to a new featureCategorizes issue or PR as related to a new feature
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).