Onboard tenant-engine to the staged-promotion contract
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 50s

TEN-WP-0008. railiance/app.toml declares criticality=high, empty secrets,
isolated canary, and the live PostgreSQL digest as previous_stable.
Manifests render through kustomize (deploy/ and deploy/canary/). Stage 1
passed. Stage 2/3 Helm-only CLI gap requested as RAIL-BS-IN-0001 rather
than a dummy chart.

Assistant: grok
Assistant-Session: 01a04cea-e5e8-7081-a0fc-808ebbc35fa9
This commit is contained in:
tegwick 2026-08-29 14:51:27 +02:00
parent f9f8e0c54f
commit 6644ad8402
19 changed files with 1053 additions and 18 deletions

View file

@ -1,6 +1,11 @@
# tenant-engine production deployment
**Apply home moving to `rapp-tenant-engine`.** These files remain the source of the absorbed manifests until that package is the operator apply path.
**Apply path:** `kubectl apply -k deploy/` (TEN-WP-0008). `deploy/base/tenant-engine.yaml`
is the document kustomize includes, and the file `make verify-pin` reads
for the intended digest. Isolated canary: `kubectl apply -k deploy/canary/`.
Staged-promotion contract: `railiance/app.toml`. Recorded stable:
`tenant-engine@sha256:a8e8086ffc5b772c1391b166f5e1884b90f7d327b152c205eceae129df555c24`.
The original manifests were recovered from live objects on 2026-08-14. The
@ -42,7 +47,7 @@ git push origin main
# 3. Provision the rapp-postgres consumer and credential projections.
# 4. Run the schema migration Job with the migration-role lease.
# 5. Follow the stopped-write transfer below; only then apply the runtime.
kubectl apply -f deploy/tenant-engine.yaml
kubectl apply -k deploy/
kubectl -n tenant-engine rollout status deploy/tenant-engine --timeout=120s
```
@ -92,7 +97,7 @@ and periodically — drift is not an event you get told about.
It compares four things that are supposed to agree:
1. the digest this repo intends to run (`deploy/tenant-engine.yaml`);
1. the digest this repo intends to run (`deploy/base/tenant-engine.yaml`);
2. the digest the Deployment's spec asks for;
3. the digest the **running pod** actually resolved — a spec can be correct
while the pod answering traffic is an older ReplicaSet that never finished