bedrock-kv / bedrock / 7e252fae5523629609cf1b26eaaa69fd2a9c1206-PR-322
82%
develop: 82%

LAST BUILD BRANCH: bedrock-5yi/election-flapping
DEFAULT BRANCH: develop
Ran
Jobs 1
Files 216
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 81.603%. Remained the same
7e252fae5523629609cf1b26eaaa69fd2a9c1206-PR-322

Pull #322

github

jallum 
bedrock-80f: Prove a real multi-node cluster can be driven from ExUnit

Phase 0 of the chaos-testing harness. Bedrock's identity is node-keyed --
coordinator_nodes is a list of node(), capabilities are per-node config, and
ClusterSupervisor refuses to start on :nonode@nohost -- so a single BEAM cannot
host a multi-coordinator cluster and nothing about coordinator failover is
testable without real distribution. The repo had no facility for that at all.

This adds the smallest thing that settles whether the harness is viable: three
:peer nodes forming one cluster, committing a transaction on one node and
reading it back from another. Green 5/5 consecutive runs, no orphaned beam
processes, no leftover temp dirs.

Three things had to be true that were not obvious:

Object storage has to be shared. Cluster bootstrap state lives there, so giving
each node its own store yields N nodes that each bootstrap a separate cluster
and never converge. One LocalFilesystem root serves all three, which also keeps
MinIO out of this entirely.

The cluster cannot be started through a bare erpc call. :erpc.call runs work in
a process that exits as soon as it has a result and signals that result as its
exit reason, so a supervisor started from inside it is linked to a process that
is already dying. An unlinked owner on the peer holds the tree instead.

Workload code has to live in compiled test/support. Peers inherit the primary's
code paths, but .exs files are only ever evaluated in the primary VM, so a
closure built in a test file has no module on the peer.

Readiness deliberately checks two things. ClusterSupervisor.child_spec/1 falls
back to a single-node descriptor when it cannot read the file, so three healthy
one-node clusters look like success; requiring every node to agree on the full
coordinator set is what separates that from a real cluster. Only then does it
wait for a transaction system layout, which exists only after recovery.

Tagged :chaos and gated on BEDROC... (continued)
Pull Request #322: bedrock-80f: prove a real multi-node cluster can be driven from ExUnit

7177 of 8795 relevant lines covered (81.6%)

1162.48 hits per line

Jobs
ID Job ID Ran Files Coverage
1 7e252fae5523629609cf1b26eaaa69fd2a9c1206-PR-322.1 216
81.6
GitHub Action Run
Source Files on build 7e252fae5523629609cf1b26eaaa69fd2a9c1206-PR-322