hub v0.81.0 — E-2: backup_target_absent gets its own signal (ships first)
An event type the hub does not allowlist makes POST /event return 400 and the
event vanishes (R-97a). The controller cannot emit backup_target_absent until
this is live, so the hub half ships first.
E-2 Phase 0 established that an absent backup target has NO prompt signal today.
The controller's drive-gate path stops apps and logs a WARN but emits nothing:
NotifyStorageDisconnected is defined and never called anywhere (verified against
the gitignored-cmd/ trap with a positive control). A drive that is ONLY a backup
target has no apps to stop, so it is entirely silent. The sole signal is the
tier's own failure at its next due cycle -- up to ~24h on the daily local tier,
which is the R-100 shape: a real fault visible only after a deadline elapses.
Added to BOTH registers, because each half fails differently:
allowedEventTypes -- without it the event is lost at the door;
customerMessages -- without it the event IS delivered but in the controller's
raw operator English, and nothing looks broken.
backup_target_absent is deliberately NOT folded into storage_disconnected: that
says "a drive went away and some apps may have stopped"; this says "the thing
that makes your backup survive a disk failure is gone".
Hungarian copy names the consequence, not just the fact. backup_target_restored
is the paired recovery at info severity -- severityNotifies NOT widened.
Three tests pin the pair and the copy's substance. All red-proofed with the
mutation VERIFIED to have landed first: the initial attempt silently no-op'd
(gofmt had realigned the map) and the test "passed" -- a false proof that would
have been reported as evidence.
Green gate: build + vet + test rc=0, run separately from this commit.
This commit is contained in:
@@ -1595,8 +1595,16 @@ var allowedEventTypes = map[string]bool{
|
||||
"offbox_repo_reset": true,
|
||||
"storage_disconnected": true,
|
||||
"storage_reconnected": true,
|
||||
"disk_warning": true,
|
||||
"disk_critical": true,
|
||||
// controller v0.184.0 (E-2) — the assigned whole-guest backup TARGET drive is absent. Distinct
|
||||
// from storage_disconnected on purpose: that one says "a drive went away and some apps may have
|
||||
// stopped"; this one says "the thing that makes a backup survive a disk failure is gone", which
|
||||
// is a different action for the customer and a different urgency for the operator. Before this
|
||||
// the only signal was the tier's own failure at its next due cycle — up to ~24 h on the daily
|
||||
// local tier — i.e. the R-100 shape: a real fault visible only after a deadline elapsed.
|
||||
"backup_target_absent": true,
|
||||
"backup_target_restored": true,
|
||||
"disk_warning": true,
|
||||
"disk_critical": true,
|
||||
// controller v0.169.0 — per-disk SMART degradation (Rendben→Figyelmeztetés/Hiba). The controller
|
||||
// sends a dynamic Hungarian message (disk label + the triggering attribute names), so — like
|
||||
// offbox_enlarge_blocked — there is deliberately NO customerMessages entry (which would discard the
|
||||
|
||||
Reference in New Issue
Block a user