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

docs: record knative admission and identity-grouping caveats

Browse source 
rail-knative is verified as a runtime but not production-approved.
Keep rapp-user-engine a single-repo pilot; a future grouped
rapp-netkingdom-identity is only legal if members share rollback fate.
This commit is contained in:
tegwick 2026-08-18 12:20:27 +02:00
parent f285b2f315
commit 56cc9099a3
1 changed files with 9 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

11
docs/RailianceAppDeploymentGuide.md
View file

@ -71,7 +71,7 @@ Grouping is legitimate only where members share rollout and rollback fate.
| Rail | Kind | Architecture | Readiness | Use when |
| --- | --- | --- | --- | --- |
| `rail-kubernetes` | base | Kubernetes | verified | Default for platform services **and** managed applications |
| `rail-knative` | derived from `rail-kubernetes` | Knative Serving on Kubernetes | verified | Scale-to-zero, revision traffic, request activation (today: Qonto) |
| `rail-knative` | derived from `rail-kubernetes` | Knative Serving on Kubernetes | rail.yaml `verified`; reef binding not production-approved | Scale-to-zero, revision traffic, request activation (today: Qonto). Serving 1.22.0 is installed on Railiance01; single-node control plane still blocks production approval. |
Default bias: use `rail-kubernetes` unless the workload truly needs
Knative lifecycle semantics. Do not invent a new rail for an adapter or
@ -554,7 +554,7 @@ all three before the first declaration validates.
| `data_classification` | `confidential` | identity and account data |
| `criticality` | `high` | shared identity-domain service; not the secrets/postgres critical path |
| `exposure` | omit (private) | operator tunnel later if needed; public grant only with a hostname and residual-risk owner |
| Granularity | single-repo rapp | one deployable; do not group with tenant-engine or secrets-engine |
| Granularity | single-repo rapp **for the pilot** | one deployable; do not group with tenant-engine or secrets-engine unless they share rollback fate. `rapp-first-wave-candidates.md` still flags a future grouped `rapp-netkingdom-identity` (user-engine + tenant-engine + key-cape + flex-auth). That grouping is only legal if those members cannot roll back independently — they almost certainly can. Treat the grouped name as a later composition question, not as a reason to leave `rapp-user-engine` undeclared. |
### 10.3 Draft declaration (index, not authority)
@ -843,6 +843,13 @@ Recorded so the scaffolder does not silently pick a side.
7. **Metrics and Host-validated apps** need extra chart care. The
scaffolder should read probe paths from the app if present
(`/healthz`, `/readyz` for user-engine) and not assume `/health`.
8. **Grouped identity vs single-engine stubs.** Architecture still
mentions folding `rapp-user-engine` into `rapp-netkingdom-identity`.
ADR-0007 only allows that if members share rollout and rollback fate.
`rapp-secrets-engine` is also a suspect duplicate of `rapp-openbao` /
S3 custody, not a fourth identity member. The pilot declares
`rapp-user-engine` alone; a later composition change is a new
declaration, not a rename of the stub.
---