coulomb/repo-manager
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(RMGR-WP-0005): registrar fix is gated on the railiance01 remote sweep

Browse source 
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 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 09:37:49 +02:00
parent 72a01c0b2f
commit de97132aef
1 changed files with 40 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

43
workplans/RMGR-WP-0005-registrar-consolidation-deterministic-ids.md
View file

@ -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