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

Start TEN-WP-0005-T05: recover deploy manifests and add CI image build
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 20s
Details

Browse source 
Production still serves the TEN-WP-0004 image, which has no lifecycle
routes. Recover the live railiance01 objects into deploy/ so rollback
does not depend on a cluster annotation, and add the fleet CI image
workflow so the lifecycle image is built from a forge revision.
This commit is contained in:
tegwick 2026-08-14 01:37:44 +02:00
parent baf41a7765
commit 7e68cc835e
4 changed files with 263 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

55
deploy/README.md Normal file
View file

@ -0,0 +1,55 @@
# tenant-engine production deployment
Manifests recovered from the live objects'
`kubectl.kubernetes.io/last-applied-configuration` on 2026-08-14 so that a
rollback does not depend on a cluster annotation. Applied originally during
TEN-WP-0004; TEN-WP-0005 keeps them in-repo and pins by digest.
| File | Deployment | Service DNS |
| --- | --- | --- |
| `tenant-engine.yaml` | `tenant-engine` | `tenant-engine.tenant-engine.svc.cluster.local:8090` |
The file is a five-document manifest: `Namespace`, `PersistentVolumeClaim`,
`Deployment`, `Service`, and a least-privilege `NetworkPolicy`. Ingress is
restricted to the `user-engine` workload; egress is restricted to
`flex-auth-tenant-engine` on 8080 plus cluster DNS.
## Rolling out an image
**Do not build images on a workstation.** `.forgejo/workflows/image.yaml`
builds from a pushed forge commit on the `container-build` runner.
```bash
# 1. Push the commit you intend to ship; CI builds :latest and :main-<short-sha>
git push origin main
# 2. Take the immutable digest from the workflow's "Report immutable digest"
# step -- deploy by digest, never by tag
# 3. Edit the image digest in deploy/tenant-engine.yaml, then apply
kubectl apply -f deploy/tenant-engine.yaml
kubectl -n tenant-engine rollout status deploy/tenant-engine --timeout=120s
```
The Deployment uses `Recreate` because the SQLite PVC is `ReadWriteOnce`.
A new pod applies the forward-only lifecycle migration on startup against
the existing database.
## Rollback
```bash
kubectl -n tenant-engine rollout undo deploy/tenant-engine
```
If the ReplicaSet history has been pruned, re-apply the manifest with the
last-known-good digest below.
| Deployment | Digest | State |
| --- | --- | --- |
| `tenant-engine` | `sha256:2249e8c6ee44ae36081cddc52daf9c3f63acd18a95a5d620ab4fa7ac85149207` | **current** — TEN-WP-0004 create/role/plan API, live since 2026-08-09 |
| `tenant-engine` *(earlier)* | `sha256:33c5dd84eaf1c2f5e067c04931219e13f9348a764a153d641035a6d019095d4f` | first TEN-WP-0004 revision |
Rolling back to `2249e8c6…` removes the lifecycle routes (`GET /tenants/{id}`,
`PATCH`, retire, reactivate). Create, role grant/revoke, and plan assign keep
working. The SQLite lifecycle columns added by the TEN-WP-0005 migration are
forward-only and stay in place; the older image ignores them.