Bootstrap the first rail-kubernetes repo
This commit is contained in:
parent
e6867e5ca9
commit
513407acaa
13 changed files with 433 additions and 0 deletions
55
INTENT.md
Normal file
55
INTENT.md
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
# INTENT
|
||||
|
||||
## Why This Repo Exists
|
||||
|
||||
`rail-kubernetes` exists so Railiance has a first-class home for the default
|
||||
execution rail used by platform services and managed workloads.
|
||||
|
||||
Before this repo, generic workload lifecycle semantics, workload declarations,
|
||||
and Kubernetes rollout helpers were mixed into `railiance-cluster`. That was
|
||||
pragmatic while Railiance had only one runtime path, but it is the wrong steady
|
||||
state once Railiance starts introducing multiple rails.
|
||||
|
||||
This repo establishes the durable answer to:
|
||||
|
||||
- how a Railiance-managed workload targets Kubernetes as a rail
|
||||
- which workload lifecycle semantics are generic to Kubernetes-managed
|
||||
workloads
|
||||
- which substrate guarantees the rail expects from S2
|
||||
- where future packages such as `rapp-openbao` attach when they run on the
|
||||
default rail
|
||||
|
||||
## What This Repo Must Protect
|
||||
|
||||
This repo must keep the wave-1 Kubernetes rail narrow and reusable.
|
||||
|
||||
That means:
|
||||
|
||||
- protect the distinction between rail semantics and cluster ownership
|
||||
- protect the distinction between rail semantics and workload packaging
|
||||
- keep the compatibility path from `railiance-cluster` explicit while the
|
||||
extraction is incomplete
|
||||
- avoid encoding assumptions that only work for one workload or one substrate
|
||||
|
||||
## What This Repo Is Not
|
||||
|
||||
This repo is not:
|
||||
|
||||
- the ownership home for the Kubernetes substrate
|
||||
- the ownership home for OpenBao, Forgejo, or any other single workload
|
||||
- the ownership home for one specific server or cluster substrate
|
||||
- the place to normalize workload-specific operator commands
|
||||
|
||||
## Initial Operating Context
|
||||
|
||||
Wave 1 is intentionally centered on Kubernetes.
|
||||
|
||||
Railiance should treat this repo as the default rail path until a later
|
||||
workload presents a strong enough reason to justify a different rail such as
|
||||
`rail-knative`.
|
||||
|
||||
The first version of this repo therefore prioritizes:
|
||||
|
||||
- a clean boundary with `railiance-cluster`
|
||||
- a stable attachment point for future `rapp-*` repos
|
||||
- compatibility with the currently published S2 substrate profile
|
||||
Loading…
Add table
Add a link
Reference in a new issue