Document rapp-openbao compatibility handoff
This commit is contained in:
parent
963b1caceb
commit
09c6e41caa
6 changed files with 131 additions and 19 deletions
16
SCOPE.md
16
SCOPE.md
|
|
@ -22,9 +22,9 @@ cnpg-system namespace) as the canonical database operator. Valkey cluster is
|
|||
also in scope for S3 extraction from S2.
|
||||
|
||||
OpenBao is a platform capability in this repo, but not every OpenBao-related
|
||||
file necessarily belongs in the long-term S3 ownership home. Deployment package
|
||||
assets are being separated from custody, policy, and lane governance as part of
|
||||
the future `rapp-openbao` extraction.
|
||||
file belongs in the long-term S3 ownership home. The deployable package surface
|
||||
now has a wave-1 repo home in `rapp-openbao`, while this repo retains custody,
|
||||
policy, and lane governance.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ the future `rapp-openbao` extraction.
|
|||
- Kubernetes runtime → railiance-cluster (S2)
|
||||
- Developer tooling, CI/CD → railiance-enablement (S4)
|
||||
- Application deployments → railiance-apps (S5)
|
||||
- Standalone workload-package ownership for OpenBao deployment assets -> future `rapp-openbao`, while S3 retains secrets custody and policy
|
||||
- Standalone workload-package ownership for OpenBao deployment assets -> `rapp-openbao`, while S3 retains secrets custody and policy
|
||||
- No re-configuration of S1/S2 concerns from this repo
|
||||
|
||||
---
|
||||
|
|
@ -71,11 +71,13 @@ the future `rapp-openbao` extraction.
|
|||
|
||||
## Current State
|
||||
|
||||
- Status: active / emerging
|
||||
- Status: maintained / emerging
|
||||
- Implementation: CloudNative PG operator (cnpg) deployed; `databases` namespace active; OpenBao is live as the S3 secrets service; Valkey + legacy postgresql-ha extraction from S2 remain in progress
|
||||
- Stability: emerging — cnpg deployed but database cluster definitions not yet migrated from S2
|
||||
- Usage: shared database, cache, and secrets layer; cnpg-system, databases, and openbao namespaces are live
|
||||
- Open work: `RAILIANCE-WP-0012` rapp-openbao extraction boundary (active); `RAILIANCE-WP-0013` Forgejo admin PAT OpenBao consumer cutover (active)
|
||||
- Open work: Valkey and legacy postgresql-ha extraction remain active; the
|
||||
OpenBao package boundary and PAT consumer cutover are now documented and
|
||||
closed
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -90,7 +92,7 @@ the future `rapp-openbao` extraction.
|
|||
## Terminology
|
||||
|
||||
- Preferred terms: OAS Stack Level S3, platform services, boundary rule, migration (extracting from S2 subcharts)
|
||||
- Potentially confusing terms: "migration" here means moving Helm releases between layers, not database schema migration; `rapp-openbao` would package OpenBao, but it would not own platform custody or policy
|
||||
- Potentially confusing terms: "migration" here means moving Helm releases between layers, not database schema migration; `rapp-openbao` packages OpenBao, but it does not own platform custody or policy
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue