From 477ad731497346e9e12d545e54753a3951dcb77d Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 8 Aug 2026 22:44:10 +0200 Subject: [PATCH] Align State Hub migration with ThreePhoenix --- .../CUST-WP-0038-state-hub-threephoenix-ha.md | 24 ++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/workplans/CUST-WP-0038-state-hub-threephoenix-ha.md b/workplans/CUST-WP-0038-state-hub-threephoenix-ha.md index 18857dd..6badd71 100644 --- a/workplans/CUST-WP-0038-state-hub-threephoenix-ha.md +++ b/workplans/CUST-WP-0038-state-hub-threephoenix-ha.md @@ -8,7 +8,7 @@ status: backlog owner: custodian topic_slug: custodian created: "2026-05-02" -updated: "2026-07-07" +updated: "2026-08-08" depends_on: CUST-WP-0011 state_hub_workstream_id: "8d0c1b5d-44da-4b91-8357-e6526d3e0a85" --- @@ -49,10 +49,16 @@ keeps the ultimate target visible and reviewable. - Railiance architecture decision for storage replication is current: Longhorn, cnpg replication, external backup, or a documented replacement. - Backup and restore tooling has an owner and runbook. +- `RAIL-BS-WP-0007` has published a passing ThreePhoenix one-server-loss + acceptance record. This workplan consumes that S2 evidence; it does not own + Kubernetes topology or cluster-runtime readiness. ## Target Properties -- Three healthy Kubernetes nodes: Railiance01, Railiance02, Railiance03. +- Three healthy Kubernetes server nodes mapped to source-backed + `reef-railiance` members and documented failure domains. Railiance01 is the + current member; future member names must come from reef/S1 declarations + rather than being assumed here. - State Hub database survives loss of one node. - State Hub API recovers from pod loss without manual repair. - Backups are encrypted, off-node, and restorable into a test namespace. @@ -76,9 +82,13 @@ Verify the target cluster state: - Control-plane and worker roles are documented. - Cluster version and node resources are recorded. - Smoke tests pass from the operator machine and from CoulombCore. +- The current `RAIL-BS-WP-0007` acceptance record proves etcd quorum, API, + scheduling, DNS, networking, and the private service path survive loss of + any one server. **Done when:** a current readiness report exists and no node is marked -NotReady or operationally unknown. +NotReady or operationally unknown, and the report cites the passing S2 +one-server-loss evidence. --- @@ -164,6 +174,10 @@ Checks: - API behavior during failover is observed. - Recovery time is measured. - No data loss is detected after recovery. +- The failure trigger removes the node hosting the database primary, not only + the database pod, and API behavior is observed throughout node loss. +- Kubernetes control-plane continuity is cited from `RAIL-BS-WP-0007`; this + task records the State Hub-specific database and API result. **Done when:** the failover drill passes and results are logged. @@ -241,6 +255,10 @@ model, and the cluster runbook is the source of truth. ## References - `CUST-WP-0011` — pragmatic railiance01 migration +- `railiance-cluster/RAIL-BS-WP-0007` — ThreePhoenix S2 topology and + one-server-loss acceptance evidence +- `reef-railiance/REEF-RAILIANCE-WP-0003` — separate Qonto workload + production gate; not satisfied by the State Hub migration - Railiance ThreePhoenix infrastructure goal - State Hub backup/restore runbooks - Constitution constraint: irreversible retirement requires human approval