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

Pin apps-pg targets to railiance01 by cluster identity; seed RPF-WP-0020
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Two reachable clusters each carry a CNPG Cluster named apps-pg in a
namespace named databases. KUBECONFIG is an environment variable, so the
Makefile ?= default never applied, and RAILIANCE01_KUBECONFIG pointed at
config-hosteurope - a different cluster. Had the environment pointed at the
other reachable cluster instead of an unauthorized one, make apps-pg-deploy
would have applied RPF-WP-0019 connection limits, role timeouts and backup
config to the wrong cluster and reported success. The Unauthorized error was
the only thing that prevented it.

Filename selection cannot protect against this: both kubeconfigs resolve to
a 127.0.0.1 tunnel port and the environment wins either way. railiance01-guard
pins identity instead, comparing the live kube-system namespace UID against
RAILIANCE01_CLUSTER_UID, and fails closed on mismatch or unreachability. It
gates apps-pg deploy, backup-deploy, overflow-dry-run, status and shell.
Verified refusing on the wrong cluster, refusing when unreachable, and
passing on railiance01. Not global: db-status legitimately targets the other
cluster for gitea-db.

RPF-WP-0019 blocker note corrected - the cluster was never unreachable, our
wiring was wrong.

RPF-WP-0020 seeded for the pre-existing CCR test failure, which is two
unrelated problems: CCR-2026-0010 is an active lane missing its whole
openbao.auth block, and CCR-2026-0011 is an honest in-flight draft the suite
has no way to express.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-08-18 15:18:37 +02:00
parent 1cbde550b5
commit b1f973c2d5
4 changed files with 227 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

36
workplans/RPF-WP-0019-apps-pg-recoverability-and-controls.md
View file

@ -85,12 +85,36 @@ against a live shared rail, in this order:
already.
5. T04's probes, in an announced window, after 1–3 have settled.
**Blocker as of this session:** the cluster is unreachable from the
workstation — `kubectl` returns `Unauthorized` against
`config-hosteurope`. Credentials or the tunnel need attention before any of
the above runs. This is a session-local access problem, not a defect in the
manifests: `make apps-pg-verify-capacity` passes and the capacity tests are
green.
**Blocker resolved 2026-08-18, and it was ours.** The earlier note recorded
this as `kubectl` returning `Unauthorized` — an access problem outside the
repo. That was wrong. railiance01 is reachable and healthy
(`~/.kube/config-railiance01`, k3s v1.35.1, `apps-pg` 9d, both consumers
present). What failed was our own wiring: `KUBECONFIG` is an environment
variable, so the Makefile's `?=` default never applied, and
`RAILIANCE01_KUBECONFIG` pointed at `config-hosteurope` — a different cluster
that happens to be unauthorized from here.
**The near-miss is the finding.** Two reachable clusters each carry a CNPG
`Cluster` named `apps-pg` in a namespace named `databases`. The other one
(k3s v1.30.3) holds `gitea-db` and only one apps-pg consumer. Had `KUBECONFIG`
pointed there instead of at an unauthorized file, `make apps-pg-deploy` would
have applied this workplan's connection limits, role timeouts and backup
configuration **to the wrong cluster, and reported success.** The
`Unauthorized` error was the only thing that prevented it.
Fixed by pinning cluster *identity* rather than kubeconfig *filename*:
`railiance01-guard` compares the live `kube-system` namespace UID against
`RAILIANCE01_CLUSTER_UID` and fails closed on mismatch or unreachability. It
gates `apps-pg-deploy`, `apps-pg-backup-deploy`, `apps-pg-overflow-dry-run`,
`apps-pg-status` and `apps-pg-shell`. Filename selection could not have
protected against this: both kubeconfigs resolve to a `127.0.0.1` tunnel port,
and the environment overrides the default either way. `make cluster-id` prints
what is currently selected.
The guard is deliberately **not** global. `db-status` legitimately targets the
other cluster for `gitea-db`, so a blanket guard would break a working target
and teach people to bypass it.
**Do not treat the rollout as evidence.** T04's P1 claim and the R-axis both
need artifacts produced *after* application, and `docs/placement-policy.md`