Evidence
docs/dr/runbook.md (Scenario 2) says:
KSail releases before the fix in devantler-tech/ksail#5359 read the cluster's current version from a single node, so the next cluster update mis-reads the cluster as already upgraded and silently skips the laggards (the deploy stays green while the stragglers never move).
[…] Once the platform tracks a KSail release containing the fix, cluster update resumes interrupted upgrades on its own.
That condition is met and has been for a while:
- ksail#5359 merged 2026-06-20.
- The deploy pins KSail 7.178.20 (
.github/actions/deploy-prod/action.yml).
- Its merge commit
d24fa750 is an ancestor of v7.178.20, verified directly.
Impact
The note reads as a live caveat, so it invites diagnosing a current deploy as hitting a bug that cannot occur on the pinned version. That happened during the 2026-08-09 gate release: after a deploy that upgraded the six static nodes, three nodes remained on older Talos and this note made "KSail skipped the laggards" look like the answer. It was wrong — the three are autoscaler-created cattle, which cluster update does not upgrade in place; every node KSail manages was current.
Suggested shape
State the as-is: cluster update resumes interrupted upgrades, and the manual per-node talosctl upgrade path is recovery for a genuinely stuck node rather than a standing workaround. Keep the manual commands — they are still the recovery — but drop the version-conditional framing.
While there, it is worth saying explicitly that autoscaler nodes are not upgraded in place: they boot from the Talos snapshot at creation and are replaced by the autoscaler, so a version spread between static and autoscale nodes after an upgrade is expected, not a stalled rollout. Nothing in the runbook says this today, and its absence is what made the correct behaviour look like a fault.
Evidence
docs/dr/runbook.md(Scenario 2) says:That condition is met and has been for a while:
.github/actions/deploy-prod/action.yml).d24fa750is an ancestor ofv7.178.20, verified directly.Impact
The note reads as a live caveat, so it invites diagnosing a current deploy as hitting a bug that cannot occur on the pinned version. That happened during the 2026-08-09 gate release: after a deploy that upgraded the six static nodes, three nodes remained on older Talos and this note made "KSail skipped the laggards" look like the answer. It was wrong — the three are autoscaler-created cattle, which
cluster updatedoes not upgrade in place; every node KSail manages was current.Suggested shape
State the as-is:
cluster updateresumes interrupted upgrades, and the manual per-nodetalosctl upgradepath is recovery for a genuinely stuck node rather than a standing workaround. Keep the manual commands — they are still the recovery — but drop the version-conditional framing.While there, it is worth saying explicitly that autoscaler nodes are not upgraded in place: they boot from the Talos snapshot at creation and are replaced by the autoscaler, so a version spread between static and autoscale nodes after an upgrade is expected, not a stalled rollout. Nothing in the runbook says this today, and its absence is what made the correct behaviour look like a fault.