Skip to content

Document journal-copy replacement and correct failure-domain sizing rules - #203

Merged
noctarius merged 4 commits into
mainfrom
docs/failure-domain-journal-replacement
Sep 4, 2026
Merged

Document journal-copy replacement and correct failure-domain sizing rules#203
noctarius merged 4 commits into
mainfrom
docs/failure-domain-journal-replacement

Conversation

@wmousa

@wmousa wmousa commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

Documents the journal-copy replacement behavior on failure-domain node removal,
and corrects two claims that no longer matched the code:

  • "At least parity chunks + 1 domains" for surviving a domain outage was the
    bare rotation-correctness floor, not the actual activation gate. Fresh
    activation now hard-requires parity chunks + 2 distinct domains (2 domains
    is never sufficient, at any parity-chunk count) so a later single add/remove
    always has a spare host to relocate onto, rather than stranding a failover
    path immediately.
  • "If no such node exists, the removal is refused" skipped a fallback: the
    control plane now splices a stranded failover path into an already-formed
    pairing (rebuilding that host's own path elsewhere) before actually
    refusing the removal.

Adds a "Journal Copy Replacement on Removal" section to the architecture
concept page (cross-referenced from both the Kubernetes and non-Kubernetes
operations pages), and replaces the old goal/recommendation table with a
domain-count x erasure-coding-scheme sizing table showing exactly how much
simultaneous node or domain loss each combination tolerates -- derived
directly from the same per-domain risk-budget formula the node-shutdown
capacity check uses (chunks_per_domain = ceil((ndcs+npcs) / domains), capped
contribution per domain, summed against a parity-chunks budget), not guessed.

Verified with scripts/quality-gate.sh (spelling, terminology, american,
prose, voice, punctuation, syntax) -- clean for all three touched files; the
syntax gate's remaining failures are pre-existing broken CLI-reference links
in unrelated, untouched files.

@noctarius
noctarius force-pushed the docs/failure-domain-journal-replacement branch from 1dbcfc7 to 7f2a6df Compare August 31, 2026 20:16
@noctarius

Copy link
Copy Markdown
Collaborator

@wmousa I've added another commit with style alignment. Can you please verify it 7f2a6df1b337c62fe338dacb91ef7150ee880334?

@github-actions

Copy link
Copy Markdown
Contributor

@noctarius

Copy link
Copy Markdown
Collaborator

@wmousa ?

@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

@wmousa

wmousa commented Sep 4, 2026

Copy link
Copy Markdown
Contributor Author

Verified 7f2a6df — looks good, please go ahead.

Checked it as a factual review rather than just prose, since it touches the sizing rules:

  • The style/prose changes (rewording the intro, the risk-budget bullets, the "1 whole domain" explanation, the 1 – 22 or fewer row label) read cleaner than what I had and don't change meaning. Agreed on all of them.
  • The one new factual claim — "A reactivation of an existing layout is only warned about, never blocked" — is correct. In cluster_ops.py the domain-count warning sits outside the if is_fresh_activation: block, and the comment above it states the intent explicitly: the warning uses the same npcs + 2 number "so a reactivation that's short of it gets the same signal without being blocked (recovering a drifted layout must not turn into an outage)." The hard gates (equal hosts per domain, host-spans-one-domain, minimum domain count) are all inside the fresh-activation branch.

I also happened to confirm this on hardware today: a cluster whose previous status was unready had the hard equal-hosts gate refuse activation at a 2/2/1/1 split, and the same activation went through once the previous status was degraded — i.e. fresh enforces, reactivation doesn't. Matches the text exactly.

Rebasing onto main now (the branch had fallen 16 commits behind); no content changes with it.

wmousa and others added 4 commits September 4, 2026 11:33
… removal

Failure-domain node removal already documented that failover-path
relocation can require a cross-domain target and refuses the removal if
none exists. It never documented the journal (JM) redundancy set's own
replacement behavior, which runs at the same time but in the opposite
direction: the control plane prefers a replacement from the departed
node's own failure domain, to leave the set's domain distribution
unchanged rather than reshuffled -- a best-effort preference, never a
removal blocker.

Adds a new "Journal Copy Replacement on Removal" section to the
architecture concept page, and cross-references it from both the
Kubernetes and non-Kubernetes "failure domain" operations pages, next to
their existing failover-path relocation coverage.

Verified with scripts/quality-gate.sh (spelling, terminology, american,
prose, voice, punctuation, syntax) -- clean for all three files.
…zing table

Two claims in the failure-domain docs no longer matched the code:

- "At least parity chunks + 1 domains" for surviving a domain outage was
  the bare rotation-correctness floor, not the actual activation gate.
  Fresh activation now hard-requires parity chunks + 2 distinct domains
  (2 domains is never sufficient, at any parity-chunk count) so a later
  single add/remove always has a spare host to relocate onto, rather than
  stranding a failover path immediately.
- "If no such node exists, the removal is refused" skipped a fallback:
  the control plane now splices a stranded failover path into an
  already-formed pairing (rebuilding that host's own path elsewhere)
  before actually refusing the removal.

Replaces the old goal/recommendation table with a domain-count x
erasure-coding-scheme sizing table showing exactly how much simultaneous
node or domain loss each combination tolerates, derived from the same
per-domain risk-budget formula the node-shutdown capacity check uses
(chunks_per_domain = ceil((ndcs+npcs) / domains), capped contribution per
domain, summed against a parity-chunks budget).

Verified with scripts/quality-gate.sh (spelling, terminology, american,
prose, voice, punctuation, syntax) -- clean for both files; the syntax
gate's remaining failures are pre-existing broken CLI-reference links in
unrelated, untouched files.
The failure-domain pages covered the balance rules a removal has to satisfy
but never said what removal is for, and the omission hides a trap that only
shows up on the second failure.

Domain balance counts every host that has not been removed, whatever its
state (failure_domain_host_map skips only STATUS_REMOVED and dedicated
secondaries), so a dead host left in the cluster still occupies its domain's
slot while serving nothing. The first such host can still be removed -- its
domain drops one below the others, which the +/-1 rule permits. If a second
host in the same domain fails first, only one of the two can go: removing the
second would leave that domain two hosts below the others and, on a
three-host domain, below the two-host floor, and admission refuses it. The
degradation then cannot be cleared by removal at all until hosts are added.

Adds a "When to Remove a Node" section to the architecture concept page
stating the two intended uses (retiring a failed host, shrinking a cluster),
that an offline or unreachable node can still be removed so removal is the
intended path for a dead host rather than a last resort, the two-failure trap
above, the two ways to restore balance afterwards, and the admission
conditions an operator can act on -- no volumes or snapshots on the node, the
+/-1 and two-host rules, a valid host-disjoint target for every failover path
the node hosts, and node headroom above data+parity counting hosts already
not online.

Cross-references it from the Kubernetes and non-Kubernetes "failure domain"
operations pages, next to their existing removal coverage.

Verified with scripts/quality-gate.sh: spelling, terminology, american,
prose, voice and punctuation clean. The syntax gate's failures are the same
pre-existing broken CLI-reference links in unrelated, untouched files; none
of the three files changed here appears among them.
@wmousa
wmousa force-pushed the docs/failure-domain-journal-replacement branch from 476961a to d69870f Compare September 4, 2026 09:33
@github-actions

github-actions Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

@noctarius
noctarius enabled auto-merge September 4, 2026 11:10
@noctarius
noctarius disabled auto-merge September 4, 2026 11:10
@noctarius
noctarius merged commit c5c6b77 into main Sep 4, 2026
6 checks passed
@noctarius
noctarius deleted the docs/failure-domain-journal-replacement branch September 4, 2026 11:10
@github-actions

github-actions Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants