bedrock-kv / bedrock / 153a2b626a39a3f370c0bdbbefd8db745a41324d

82%

Build Type

push

github

Committed by web-flow

Commit Message

bedrock-3t9: seed a fresh cluster's sizing from the node config the durability check validates (#323)

Tracks bedrock-3t9.

## Why

Strict durability mode is supposed to refuse to start a cluster that
can't meet the durability profile — three logs, replication factor
three. The guides tell you to satisfy it with node config:

```elixir
config :my_app, MyCluster,
  durability_mode: :strict,
  durability: [desired_logs: 3, desired_replication_factor: 3]
```

`ClusterSupervisor.init/1` checks exactly that node config, and it
passes. But nothing ever *applied* it: a fresh cluster's parameters come
from `Config.new/1` → `Parameters.new/1`, which hardcodes `desired_logs:
1, desired_replication_factor: 1`. In a three-node harness cluster
configured as above, every node started cleanly in strict mode and the
cluster ran with a single log. `Bedrock.Durability.profile(MyCluster)` —
which prefers the live cluster config — reported `:failed`, and nothing
acted on it. The guardrail was checking a number the cluster ignored,
and there was no configuration path to more than one log at all.

## What changed

When a coordinator starts the first recovery of a fresh cluster (no
bootstrap record in object storage),
`DirectorManagement.maybe_put_default_config/1` now seeds `desired_logs`
and `desired_replication_factor` from the same evaluation the startup
check performs — `Profile.evaluate(node_config).checks.*.actual` —
instead of leaving `Config.new/1`'s hardcoded ones. Those parameters are
persisted in the first cluster bootstrap, so later boots and recoveries
keep them.

Existing clusters are untouched: once a bootstrap exists its parameters
win, and editing node config afterwards does not resize the cluster
(that needs an operator write path — bedrock-q67.51).
`guides/durability-profile.md` now says so, and that `durability:` must
be identical across coordinator nodes, since the seed comes from
whichever coordinator leads the first recovery.

## How it works

Readin... (continued)

Coverage Stats

7 of 7 new or added lines in 1 file covered. (100.0%)

2 existing lines in 2 files now uncovered.

7187 of 8801 relevant lines covered (81.66%)

1138.58 hits per line