feat(dashboard): show "nodes rolled N/M" so a red deploy says whether the fleet moved #2032

Merged
sean merged 1 commit from feat/rollout-summary into trunk 2026-08-11 16:15:16 +00:00
Owner

A kernel deploy that rolled every node and then tripped on a post-roll step renders exactly like one that rolled nothing - both just say Failed.

On 2026-08-11 the linux project showed eight red deploys while all five workers were in fact running the new kernel. The only way to tell which had actually moved the fleet was to read node kernel versions by hand. On that one page:

deploy what really happened shown as
hz666 rolled 1 node, then the canary gate expired Failed
vzkhp rolled 2 nodes, then final-verify wedged Failed
mxkfx rolled 0 nodes, died at the first agent Failed

Three very different outcomes, one indistinguishable status. The deploy phase answers "did the workflow finish" - which is not the question an operator is asking, namely "did the fleet move".

Change

Adds rollSummary() over the per-node progress the dashboard already derives from the workflow's roll-one nodes, surfaced in two places:

  • the fold's kv block - nodes rolled 2/5, coloured ok/run/bad
  • the node rollout heading

No CRD or API change - the data was already there, it simply was not counted. Shown even on a failed deploy, deliberately: that is exactly the case where it carries information.

Test

Pins the property that matters - rolled-all and rolled-none must not produce the same summary - plus the partial and not-a-kernel-roll cases.

A kernel deploy that rolled **every** node and then tripped on a post-roll step renders exactly like one that rolled **nothing** - both just say `Failed`. On 2026-08-11 the `linux` project showed eight red deploys while all five workers were in fact running the new kernel. The only way to tell which had actually moved the fleet was to read node kernel versions by hand. On that one page: | deploy | what really happened | shown as | |---|---|---| | `hz666` | rolled **1** node, then the canary gate expired | Failed | | `vzkhp` | rolled **2** nodes, then `final-verify` wedged | Failed | | `mxkfx` | rolled **0** nodes, died at the first agent | Failed | Three very different outcomes, one indistinguishable status. The deploy phase answers *"did the workflow finish"* - which is not the question an operator is asking, namely *"did the fleet move"*. ### Change Adds `rollSummary()` over the per-node progress the dashboard **already** derives from the workflow's `roll-one` nodes, surfaced in two places: - the fold's kv block - **`nodes rolled 2/5`**, coloured `ok`/`run`/`bad` - the `node rollout` heading **No CRD or API change** - the data was already there, it simply was not counted. Shown even on a failed deploy, deliberately: that is exactly the case where it carries information. ### Test Pins the property that matters - rolled-all and rolled-none must not produce the same summary - plus the partial and not-a-kernel-roll cases.
A kernel deploy that rolled EVERY node and then tripped on a post-roll
step renders exactly like one that rolled nothing: both just say Failed.
On 2026-08-11 the linux project showed eight red deploys while all five
workers were in fact running the new kernel, and the only way to tell
which deploys had actually moved the fleet was to read node kernel
versions by hand.

Concretely, on that one page:
  hz666  rolled 1 node, then the canary gate expired  -> Failed
  vzkhp  rolled 2 nodes, then final-verify wedged     -> Failed
  mxkfx  rolled 0 nodes, died at the first agent      -> Failed

Three very different outcomes, one indistinguishable status.

The deploy phase answers "did the workflow finish". That is not the
question an operator is asking, which is "did the fleet move".

Adds rollSummary() over the per-node progress the dashboard ALREADY
derives from the workflow's roll-one nodes, and surfaces it two places:
the fold's kv block ("nodes rolled 2/5", coloured ok/run/bad) and the
node-rollout heading. No CRD or API change -- the data was already
there, it simply was not counted.

Shown even on a failed deploy, deliberately: that is exactly the case
where it carries information.

Test pins the property that matters -- rolled-all and rolled-none must
not produce the same summary -- plus the partial and not-a-kernel-roll
cases.
sean merged commit 09319f6ab0 into trunk 2026-08-11 16:15:16 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
sean/pipelines!2032
No description provided.