From de97132aefedfa9934803a8a2fc78129573dfb5f Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 21 Aug 2026 09:37:49 +0200 Subject: [PATCH] docs(RMGR-WP-0005): registrar fix is gated on the railiance01 remote sweep The registrar fix is one env var, not host provisioning: the state-hub deployment has STATEHUB_REGISTRAR unset, and that pod is the real automated instance -- it mounts /home/tegwick rw and /home/tegwick/.ssh for push. But setting it now would be harmful. railiance01 has 70 repos still on gitea-remote (92.205.130.254) against 7 on forgejo-remote (92.205.62.239), while the workstation is 126/0 on forgejo. The pod would mint identifiers into checkouts tracking the superseded server and push them there. Records the required order -- reconcile railiance01's remotes first, then enable the registrar -- and that the sweep pod is currently operating against those stale checkouts. Co-Authored-By: Claude Opus 5 --- ...gistrar-consolidation-deterministic-ids.md | 43 +++++++++++++++++-- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/workplans/RMGR-WP-0005-registrar-consolidation-deterministic-ids.md b/workplans/RMGR-WP-0005-registrar-consolidation-deterministic-ids.md index 8acb103..cae8881 100644 --- a/workplans/RMGR-WP-0005-registrar-consolidation-deterministic-ids.md +++ b/workplans/RMGR-WP-0005-registrar-consolidation-deterministic-ids.md @@ -101,9 +101,46 @@ Two consequences beyond this task: - **Security.** The `state-hub` pod mounts `/home/tegwick` **and `/home/tegwick/.ssh`** as hostPath volumes. A workload with the operator's private keys is a larger exposure than the registrar problem it surfaced. -- **The remote sweep is incomplete.** If `railiance01` was missed, other hosts - may also still point at `gitea-remote`; anything reconciling from them compares - against a stale lineage. +- **The remote sweep is incomplete, and this gates the registrar fix.** Counted + 2026-08-21: + + | Host | `forgejo-remote` | `gitea-remote` | + | --- | --- | --- | + | workstation | 126 | 0 | + | `railiance01` | 7 | **70** | + + The two aliases are different servers — `forgejo-remote` is `92.205.62.239` + (railiance01), `gitea-remote` is `92.205.130.254` (coulombcore) — and both are + live. The workstation finished migrating; `railiance01` did not. + `forgejo-tier3-remote-url-sweep-playbook` still reads "Gitea remains canonical", + which was true when written on 2026-07-04 and is now stale guidance. + +### Why the registrar cannot simply be switched on + +The fix looked like one environment variable: the `state-hub` **deployment** has +`STATEHUB_REGISTRAR` unset, and that pod is the real automated instance — it +mounts `/home/tegwick` read-write, mounts `/home/tegwick/.ssh` at `/root/.ssh` +for push, and carries `STATE_HUB_SWEEP_HOSTNAME`. Host-level provisioning was the +wrong target. + +**Setting it today would be actively harmful.** The pod would begin minting +identifiers into 70 checkouts that track the superseded server and pushing them +there — writing hub primary keys into a lineage nothing reads, and re-animating +`gitea-remote` as a write target. + +Required order: + +1. Re-point `railiance01`'s checkouts to `forgejo-remote`, keeping `gitea` as the + rollback mirror the playbook specifies. Content diverges — `evidence-binder` + there is at `a715492` against the workstation's `9e3f4a6` — so this is a + reconcile, not a URL rewrite. +2. Then set `STATEHUB_REGISTRAR=1` on the deployment. + +Reversing the order mints into the wrong lineage at fleet scale. + +**Open question worth answering first:** the sweep pod is running now against +those 70 stale checkouts. Establish what it has been pushing to `gitea-remote` +before changing anything. ## Re-register identifiers minted outside the registrar