OnLaunch

What the Manager does with a runtime that has failed, or whose node was lost. See §3.4. Formerly "priority bands" (gold/silver/bronze), renamed because the metals implied a ranking: these are three different behaviours, not better/ok/worse.

PREFER_SPARE re-place, biasing placement toward standby nodes. AVOID_SPARE re-place, penalising unconsumed standby nodes so a routine failure does not consume a reserve held for critical work. DROP do not re-place; the runtime is terminal.

NB the numbers are the wire contract and MUST NOT change: they are persisted inside JobRequirements by the daemon, so renumbering would silently reinterpret every bundle already on disk. Note also that PREFER_SPARE is the proto3 zero value, so a message that omits the field decodes as PREFER_SPARE — which is NOT the Manager’s default (that is AVOID_SPARE, applied when a bundle is composed). What a bundle may do with hot spares WHEN IT IS FIRST LAUNCHED. Distinct from OnRuntimeFailure, which governs the same question at recovery time — two different moments, two different controls.

The reserve exists so that work which asked for a spare can recover onto one immediately, and a launch is normally scheduled with time in hand. So the default is to leave spares alone. The exception is the emergency launch — something has to be on air NOW — where taking a warm node is the right trade.

ALLOW_SPARE means the spare stops being penalised and competes as an ordinary candidate. It deliberately does NOT bias toward spares: that would be prefer, and naming it so while merely un-penalising is the kind of misleading name the OnRuntimeFailure rename exists to remove.

AVOID_SPARE is the proto3 zero value AND the default, so a message that omits the field decodes to the intended behaviour — unlike OnRuntimeFailure, where the zero value is not the default.