From a029025055c7760f8d57c6b114f28f1ecb752bf7 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 15 Aug 2026 20:52:03 +0200 Subject: [PATCH] chore: retire duplicate ThreePhoenix workplan S2 HA lives in railiance-cluster. Point here instead of keeping a second RAIL-BS-WP-0007 with the same hub ids. New bootstrap work uses RAIL-BOOT-WP-. --- AGENTS.md | 18 +- workplans/POINTER-RAIL-BS-WP-0007.md | 9 + ...RAIL-BS-WP-0007-threephoenix-ha-cluster.md | 229 ------------------ 3 files changed, 18 insertions(+), 238 deletions(-) create mode 100644 workplans/POINTER-RAIL-BS-WP-0007.md delete mode 100644 workplans/RAIL-BS-WP-0007-threephoenix-ha-cluster.md diff --git a/AGENTS.md b/AGENTS.md index 882576c..21827d5 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,12 +2,12 @@ ## Repo Identity -**Purpose:** Infrastructure bootstrap and configuration management for the railiance domain. Contains Ansible playbooks, cluster provisioning scripts, and environment safety nets. +**Purpose:** First-boot path from a bare VM to a working Railiance host, then hand off. Not the S2 cluster runtime (`railiance-cluster`) and not S1 inventory/hardening (`railiance-infra`). **Domain:** financials **Repo slug:** railiance-bootstrap **Topic ID:** `ca369340-a64e-442e-98f1-a4fa7dc74a38` -**Workplan prefix:** `RAIL-BS-WP-` +**Workplan prefix:** `RAIL-BOOT-WP-` --- @@ -169,10 +169,10 @@ get wrong. Work items originate as files in this repo — not in the hub. The hub is a read/cache/index layer that rebuilds from files. -**File location:** `workplans/RAILIANCE-WP-NNNN-.md` +**File location:** `workplans/RAIL-BOOT-WP-NNNN-.md` **Archived location:** finished workplans may move to -`workplans/archived/YYMMDD-RAILIANCE-WP-NNNN-.md`. The `YYMMDD` prefix is +`workplans/archived/YYMMDD-RAIL-BOOT-WP-NNNN-.md`. The `YYMMDD` prefix is the completion/archive date; the frontmatter `id` does not change. **Ad Hoc Tasks:** small opportunistic fixes discovered during a session use @@ -184,11 +184,11 @@ anything needing analysis, design, approval, dependencies, or multiple phases. ```yaml --- -id: RAILIANCE-WP-NNNN +id: RAIL-BOOT-WP-NNNN type: workplan title: "..." domain: financials -repo: railiance-cluster +repo: railiance-bootstrap status: proposed | ready | active | blocked | backlog | finished | archived owner: codex topic_slug: ... @@ -208,7 +208,7 @@ derived health labels, not frontmatter statuses. ## Task Title ` ` `task -id: RAILIANCE-WP-NNNN-T01 +id: RAIL-BOOT-WP-NNNN-T01 status: wait | todo | progress | done | cancel priority: high | medium | low state_hub_task_id: "" # written by fix-consistency — do not edit @@ -221,5 +221,5 @@ Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blo To create a new workplan: 1. Write the file following the format above -2. Notify the custodian operator to run `make fix-consistency REPO=railiance-cluster` - (or send a message to the hub agent via `POST /messages/`) +2. Run `statehub fix-consistency` from this checkout. Ask the operator + only if the CLI or State Hub API is unavailable. diff --git a/workplans/POINTER-RAIL-BS-WP-0007.md b/workplans/POINTER-RAIL-BS-WP-0007.md new file mode 100644 index 0000000..aa6533e --- /dev/null +++ b/workplans/POINTER-RAIL-BS-WP-0007.md @@ -0,0 +1,9 @@ +# ThreePhoenix is not owned here + +`RAIL-BS-WP-0007` is S2 cluster work. The canonical file is + +`railiance-cluster/workplans/RAIL-BS-WP-0007-threephoenix-ha-cluster.md` + +This repo bootstraps a host and then hands off. It does not implement +k3s HA, ingress, or storage. Do not re-register `RAIL-BS-WP-0007` here +— the cluster file already holds the State Hub workstream. diff --git a/workplans/RAIL-BS-WP-0007-threephoenix-ha-cluster.md b/workplans/RAIL-BS-WP-0007-threephoenix-ha-cluster.md deleted file mode 100644 index 52a7a9b..0000000 --- a/workplans/RAIL-BS-WP-0007-threephoenix-ha-cluster.md +++ /dev/null @@ -1,229 +0,0 @@ ---- -id: RAIL-BS-WP-0007 -type: workplan -title: "ThreePhoenix - HA Cluster Implementation" -domain: financials -repo: railiance-cluster -status: active -owner: railiance -topic_slug: railiance -repo_goal_id: "6ea441f7-7fe3-4598-922b-38baf20c0580" -state_hub_workstream_id: "9e208376-23f1-40c7-9813-fac1f7d6ad3b" -created: "2026-02-25" -updated: "2026-05-03" ---- - -# ThreePhoenix - HA Cluster Implementation - -## Goal - -Implement the ThreePhoenix architecture: a self-healing three-node Kubernetes -cluster substrate for Railiance production systems. - -The cluster target includes: - -- k3s HA with embedded etcd. -- Distributed storage. -- High-availability database patterns. -- Ingress and certificate automation. -- Node rotation and recovery drills. -- Monitoring and acceptance audits. - -## Why This Belongs Before Forgejo - -Forgejo will be the source forge, package base, and Actions surface for the -Railiance stack. Moving it before the production cluster lifecycle is clear -would make Forgejo both the migration target and the infrastructure experiment. - -ThreePhoenix should come first, or at least its lifecycle gates should be -designed first, so Forgejo is deployed onto a substrate whose failure and -promotion behavior is already understood. - -## Boundary - -This workplan is S2 cluster runtime work. - -In scope for `railiance-cluster`: - -- k3s HA topology and runtime configuration. -- Cluster-level storage/operator installation hooks. -- Ingress and certificate controllers. -- Cluster health, rotation, and acceptance checks. - -Out of scope: - -- Database cluster definitions and credentials: `railiance-platform`. -- Forgejo/Gitea application Helm values: `railiance-apps`. -- Developer workflows and Actions templates: `railiance-enablement`. -- OS provisioning and host hardening: `railiance-infra`. - -## Tasks - -### T01 - K3s HA cluster setup - -```task -id: RAIL-BS-WP-0007-T01 -status: todo -priority: high -state_hub_task_id: "1f8a8668-31eb-4d79-bbcd-50f6430a8d66" -``` - -Implement the three-node k3s HA cluster setup using embedded etcd. - -Minimum scope: - -- Define node roles and join sequence. -- Automate first server and additional server joins. -- Validate etcd quorum. -- Document failure behavior for one missing node. - -**Done when:** three nodes can form a healthy k3s HA cluster from documented -commands. - ---- - -### T02 - Longhorn distributed storage - -```task -id: RAIL-BS-WP-0007-T02 -status: todo -priority: high -state_hub_task_id: "b1d4e0fa-da41-4b13-a7d6-34dd040cb605" -``` - -Install and validate distributed storage for stateful workloads. - -Minimum scope: - -- Storage prerequisites and node labeling. -- Longhorn installation or approved alternative. -- Default storage class decision. -- Volume replica and recovery behavior. -- Backup target handoff to `railiance-platform` where appropriate. - -**Done when:** a test PVC survives a node disruption according to the -ThreePhoenix acceptance criteria. - ---- - -### T03 - PostgreSQL HA pattern - -```task -id: RAIL-BS-WP-0007-T03 -status: todo -priority: high -state_hub_task_id: "11283b4c-7e4d-490d-91b3-0d06a593bdf0" -``` - -Define the PostgreSQL HA runtime pattern and handoff to S3. - -The original State Hub task names repmgr and Pgpool-II. Before implementation, -reconcile that with the current Railiance production baseline using -CloudNative PG. - -**Done when:** the chosen HA database pattern is documented, tested, and -owned by the correct layer without conflicting with `railiance-platform`. - ---- - -### T04 - Reference stateful application HA - -```task -id: RAIL-BS-WP-0007-T04 -status: todo -priority: high -state_hub_task_id: "4a20e593-a89d-43da-abcc-5a39a4c8b3c0" -``` - -Validate a representative stateful source-forge workload on the HA cluster. - -The historical task names Gitea. In the current roadmap this should become -Forgejo unless a temporary Gitea reference drill is still useful. - -Minimum checks: - -- Repository storage survives pod reschedule and node disruption. -- Database failover behavior is understood. -- Package registry storage is included in backup/restore thinking. -- Application-level rollback is compatible with the staged promotion lifecycle. - -**Done when:** Railiance has a proven stateful source-forge deployment pattern -that can be reused for the Forgejo migration. - ---- - -### T05 - Nginx ingress and cert-manager SSL - -```task -id: RAIL-BS-WP-0007-T05 -status: todo -priority: medium -state_hub_task_id: "68315a40-dd5b-4032-a9e7-1152e38f9807" -``` - -Implement and validate the production ingress and certificate path. - -Minimum scope: - -- Ingress controller topology. -- TLS certificate issuance and renewal. -- Private/public exposure rules. -- Health checks for ingress and certificate validity. - -**Done when:** representative services can be exposed through the intended -ingress path with valid certificates. - ---- - -### T06 - Phoenix CronJob automation - -```task -id: RAIL-BS-WP-0007-T06 -status: todo -priority: medium -state_hub_task_id: "f658aa6a-1c48-4660-88fa-35eaa0137e12" -``` - -Implement weekly node rotation or equivalent Phoenix recovery automation. - -Minimum scope: - -- Define what "rotation" means for the current host reality. -- Automate safe cordon, drain, rebuild/rejoin, and validation steps where - feasible. -- Include explicit human gates for destructive host actions. -- Log rotation results to State Hub. - -**Done when:** the cluster recovery rhythm is scripted, documented, and tested -without risking production data. - ---- - -### T07 - Monitoring stack and acceptance audit checklist - -```task -id: RAIL-BS-WP-0007-T07 -status: todo -priority: medium -state_hub_task_id: "70f6c8ab-a700-4fb2-893e-cf5a40615044" -``` - -Add the monitoring stack and final acceptance audit checklist. - -Minimum scope: - -- Cluster health signals. -- Storage health. -- Database/operator health handoff. -- Ingress and certificate health. -- Backup/restore freshness. -- Promotion lifecycle readiness. - -**Done when:** ThreePhoenix can be declared ready for critical workloads only -after the checklist passes. - -## Dependencies - -This workplan should precede the Forgejo production cutover. It should also -shape the Stage 2 and Stage 3 gates in `RAIL-BS-WP-0006` so canaries and -promotions operate against the real HA substrate.