169 lines
6.1 KiB
Markdown
169 lines
6.1 KiB
Markdown
# First-Wave `rapp-*` Candidates
|
|
|
|
Date: 2026-07-25
|
|
|
|
## Purpose
|
|
|
|
Choose and order the first `rapp-*` candidates for Railiance.
|
|
|
|
`rapp-*` repos are for managed workload packaging and scaffolding. They are not
|
|
new ownership homes. The decision here is therefore not "which repos are
|
|
important?" but "which workloads already have a strong enough package boundary
|
|
to become first-class managed wrappers without weakening ownership?"
|
|
|
|
## Selection Criteria
|
|
|
|
The first-wave candidates should satisfy most of the following:
|
|
|
|
- stable workload identity
|
|
- clear upstream or source workload boundary
|
|
- clear Kubernetes package surface already visible in Git
|
|
- explicit runtime-secret and dependency handling
|
|
- deploy, verify, and recover behavior already described
|
|
- low ambiguity between packaging ownership and domain ownership
|
|
- good demonstration value for later `rapp-*` extractions
|
|
|
|
## Assessed Candidates
|
|
|
|
### 1. OpenBao from `railiance-platform`
|
|
|
|
Assessment: **choose first**
|
|
|
|
Why it fits:
|
|
|
|
- It is a clear third-party upstream product with durable identity.
|
|
- The workload already has a substantial Railiance packaging surface:
|
|
`helm/openbao-values.yaml`, middleware, UI overlay assets, deploy/verify
|
|
scripts, and operator runbooks.
|
|
- The repo already distinguishes between the OpenBao workload itself and the
|
|
wider S3 platform policy that consumes it.
|
|
- It is important enough to prove that `rapp-*` is not only for user-facing
|
|
apps; platform services can also be managed workloads.
|
|
|
|
What should move into `rapp-openbao`:
|
|
|
|
- Helm values and Kubernetes-facing package assets for the OpenBao workload
|
|
- UI overlay wrapper assets
|
|
- generic deploy, verify, and workload-health runbooks
|
|
- workload-specific smoke and recovery expectations
|
|
|
|
What should remain in `railiance-platform`:
|
|
|
|
- the S3 ownership of secrets custody as a platform capability
|
|
- workload lane policy, credential approval, and platform-wide access models
|
|
- cross-workload secret-delivery conventions consumed by many workloads
|
|
|
|
Conclusion:
|
|
|
|
`rapp-openbao` should be the first `rapp-*` extraction.
|
|
|
|
### 2. Forge workload from `railiance-forge`
|
|
|
|
Assessment: **defer from first wave**
|
|
|
|
Why it is not first:
|
|
|
|
- The current live workload is still Gitea on CoulombCore.
|
|
- The intended production direction is Forgejo on Railiance01.
|
|
- Packaging identity is therefore not stable enough yet: extracting now would
|
|
either enshrine a temporary Gitea compatibility package or pretend the
|
|
Forgejo cutover is already complete.
|
|
- The runtime and migration story still spans current Gitea operation, future
|
|
Forgejo deployment, runner substrate, registries, and cutover sequencing.
|
|
|
|
Decision:
|
|
|
|
- Do **not** make the forge workload the first `rapp-*` extraction.
|
|
- Prefer `rapp-forgejo` as the eventual target package once the production
|
|
direction is the real operating target.
|
|
- Create `rapp-gitea` only if Railiance discovers it needs a long-lived
|
|
compatibility wrapper for the current workload rather than a short migration
|
|
bridge.
|
|
|
|
What this means:
|
|
|
|
- `railiance-forge` keeps runtime ownership for now.
|
|
- The forge wrapper should follow after the current Gitea-versus-Forgejo
|
|
packaging identity stops moving.
|
|
|
|
Conclusion:
|
|
|
|
The forge workload is packaging-worthy, but it should not be first-wave
|
|
`rapp-*`.
|
|
|
|
### 3. User-facing S5 workload from `railiance-apps`
|
|
|
|
Assessment: **choose `vergabe-teilnahme` for wave 1**
|
|
|
|
Why `vergabe-teilnahme` wins the S5 slot:
|
|
|
|
- It is clearly user-facing and already operates as one named workload package.
|
|
- Its release surface is explicit: chart, values, ingress, deployment targets,
|
|
migration command, smoke checks, and operator runbook.
|
|
- Secret handling is clear without being entangled with shared platform
|
|
semantics: app credentials are consumed from Kubernetes Secrets and the app
|
|
env secret is locally rebuilt by operator procedure.
|
|
- It is simpler and more stable than the current Core Hub / Inter-Hub history
|
|
and more obviously user-facing than service-style workloads such as
|
|
`reuse-surface`.
|
|
|
|
What should move into `rapp-vergabe-teilnahme`:
|
|
|
|
- the chart and workload values
|
|
- the ingress and app-specific release runbook
|
|
- workload-specific rollout, migration, smoke, and rollback guidance
|
|
- workload-specific secret consumption contract
|
|
|
|
What should remain in `railiance-apps`:
|
|
|
|
- S5 ownership of generic application release patterns
|
|
- reusable onboarding and operator recipes
|
|
- cross-app S5 guardrails that should not be duplicated per workload package
|
|
|
|
Second-wave S5 note:
|
|
|
|
- `reuse-surface` is the strongest follow-on self-built service candidate after
|
|
`vergabe-teilnahme`, because it already shows explicit OpenBao-backed runtime
|
|
secret lanes and a tidy single-workload chart surface.
|
|
- `core-hub` and retired `inter-hub` should wait because their packaging
|
|
history is still entangled with cutover and legacy service evolution.
|
|
|
|
Conclusion:
|
|
|
|
`rapp-vergabe-teilnahme` should be the first user-facing S5 `rapp-*`.
|
|
|
|
## First-Wave Order
|
|
|
|
The recommended order is:
|
|
|
|
1. `rapp-openbao`
|
|
2. `rapp-vergabe-teilnahme`
|
|
3. `rapp-forgejo` after the forge runtime target is stable enough to avoid
|
|
immediate rename or migration churn
|
|
|
|
This order is intentional.
|
|
|
|
- `rapp-openbao` proves the third-party platform-service wrapper model.
|
|
- `rapp-vergabe-teilnahme` proves the self-built user-facing app wrapper model.
|
|
- The forge wrapper then follows with a clearer target identity and after the
|
|
first two wrappers have established the pattern.
|
|
|
|
## Risks To Watch
|
|
|
|
- If `rapp-openbao` absorbs platform-wide policy and credential-governance
|
|
logic, the wrapper will become a shadow S3 repo.
|
|
- If `rapp-vergabe-teilnahme` absorbs generic S5 onboarding or app recipes, it
|
|
will weaken `railiance-apps` as the shared S5 release home.
|
|
- If the forge wrapper is extracted too early, Railiance will immediately face
|
|
a Gitea-versus-Forgejo package rename or parallel-wrapper problem.
|
|
|
|
## Outcome
|
|
|
|
Railiance now has a concrete first-wave `rapp-*` sequence:
|
|
|
|
- first `rapp-openbao`
|
|
- then `rapp-vergabe-teilnahme`
|
|
- then the forge wrapper once the production package identity is stable
|
|
|
|
That is enough to start repo-local extraction planning without pretending every
|
|
workload needs its own `rapp` immediately.
|