QuantyKube

ADR-008 Raft comes later, and starts with a simulator

All pages

ADR-008, from docs/DECISIONS.md in the QuantyKube repository.

Status Partly superseded by ADR-027.

Its date is superseded by ADR-027: Raft is attempted before 17 November. How it is built stands.

Multiple store nodes with Raft are the goal of the next phase, not of the first demonstration. ADR-001 stands for that date.

Raft is short on paper and notoriously hard to get right in practice. The failures that matter, a lost acknowledged write or two leaders at once, appear only under particular interleavings of crashes, partitions and delays, and a demonstration date is the wrong pressure to build that under. The weeks before it are already filled by HTTP/2, gRPC and Watch, which everything else depends on. Raft also needs a transport between the store nodes, and across machines that transport needs TLS, which QuantyCore does not have yet.

How it will be built. The measuring instrument first: a deterministic simulator in which several nodes run in one process against a simulated network and simulated disks, with time, message order, loss, partitions and crashes all driven by a seed. Any failure is reproduced exactly from its seed. Only when the simulator can find planted bugs is the protocol written against it.

Until then, high availability comes from a PostgreSQL backend (ADR-006), the way k3s gets it from kine.

The cost: the first thing many companies will ask about, a highly available store, is answered on 17 November with a plan and not with a running system, and the talk has to say so.