0137. An operation parked for an even control-plane count does not block its own cure

Status: Accepted · Date: 2026-11-07 · Design section: Nodes · Amends: 0010 (the gate that moved to where the lock is acquired), 0085 (the plan's "another unfinished operation" refusal), 0135

Decided: an operation the controller parked with Paused reason ClusterTransitioning (the count of approved control planes is even) does not block "Remove node" of a control plane, and the plan says so. While the count is even, planning a new operation (except an etcd restore) is refused with the way out, instead of creating one that is parked at once. A parked operation resumes by itself when the count is odd.

Context

A fourth control plane was approved (3 to 4, on the way to 5), so Transitioning=True (EvenControlPlaneCount). An Ichor upgrade was created and parked at once with ClusterTransitioning. The user then removed the fourth control plane to go back to 3, and the plan refused: "operation ichor-2jfbw (ichor) is not finished (phase Paused); resume it ...". Resuming could not help (still even) and the override does not bypass the check: the action that ends the even count was blocked by an operation parked because of the even count.

Decisions

1. A parked operation holds nothing. The operation controller checks the count before it takes the cluster lock (acquireDisruptiveLock, ADR 0010), so an operation with Paused reason ClusterTransitioning and no failureReason has not acquired it. The removal of a control plane completes the transition and takes the lock itself (completesTransition), and the lock still arbitrates against an operation that does run. The plan's unfinishedOperationFor(..., resolvesTransition) therefore skips such an operation for a control-plane Remove. Any other unfinished operation (running, paused by the operator, failed) still refuses, with the old text.
2. Other callers keep the refusal, with an honest text. For them a parked operation is reported as "waits for the control-plane count to be odd again; it resumes by itself then. Remove or approve a control plane to end the replacement", not as something to resume by hand. Approving or rejecting a machine reads no operation and was never blocked by one.
3. Auto-resume. The controller already requeues a parked operation every operationRequeueInterval and re-runs the count; once it is odd the pause condition clears and the operation continues. Nothing else is bypassed: the other pause reasons (operator, lock held, shutdown, failure) are untouched. A test pins it.
4. Refuse at the plan. PlanOperation returns Blocked for every kind except an etcd restore (a recovery, which runs before the count check) while Transitioning=True: "the cluster has an even number of approved control planes (...): ... Remove a control plane (to go back down) or approve another one (to go up), then run this again". The UI and CLI already show Blocked. A reset of a control plane while the count is even is likewise refused with "Remove the node instead, which ends it", because a reset operation would be parked by the controller; Remove does not.

Rejected

• Letting every operation through the lock check while even: it would run disruptive work on an etcd without a majority margin (ADR 0010).
• Deleting a parked operation when Remove starts: it hides that the upgrade was wanted.

Risks

An operation that was already running when a control plane was added keeps the lock until it renews out; Remove then waits on the lock (HeldError, retried) rather than the plan refusing. The plan reads the cluster's Transitioning condition, which can be one reconcile stale; the controller recounts.