forked from bai/curriculum-project-hub
58 lines
2.7 KiB
Markdown
58 lines
2.7 KiB
Markdown
# ADR 0025: Alpha Uses Managed Single-Organization Silos
|
|
|
|
## Status
|
|
|
|
Accepted for the supervised alpha.
|
|
|
|
## Context
|
|
|
|
The shared SaaS control plane, durable cross-Organization admission scheduler,
|
|
and customer administration SPA are not complete. Real customer data must not
|
|
depend on partially migrated application-level tenant filtering merely to start
|
|
the supervised alpha.
|
|
|
|
## Decision
|
|
|
|
Each alpha Organization runs as a separately named Silo deployment. A Silo has
|
|
one Hub systemd unit and service identity, one logical PostgreSQL database and
|
|
database role, one workspace root, one environment/session secret, one local
|
|
master-key keyring, one Feishu Application Connection, and Organization-local
|
|
Provider Connections. The process is pinned by `HUB_SILO_ORGANIZATION_ID` and
|
|
refuses startup unless its database contains exactly that one active
|
|
Organization.
|
|
|
|
Application releases remain shared and versioned; customer state does not live
|
|
inside a release directory. Host-console bootstrap, upgrade, backup, restore,
|
|
and KEK rotation always name a Silo instance explicitly. The alpha exposes no
|
|
platform administration surface. Operators provision and support Silos through
|
|
the controlled host console and retain an external change record.
|
|
|
|
The process-local trigger queue is not an accepted-work queue in the Silo
|
|
alpha. A busy project or instance rejects new work explicitly. Each instance
|
|
has checked-in application limits and explicit systemd CPU, memory, and process
|
|
ceilings. Workspace filesystem quotas are a host provisioning prerequisite.
|
|
|
|
This topology changes deployment, not the semantic tenant root:
|
|
`Organization` remains the tenant root and every authorization, secret, audit,
|
|
Project, Team, and Run remains Organization-scoped. A later pooled or bridge
|
|
adapter may host multiple Organizations only after ADR-0022's durable admission
|
|
and platform control requirements are implemented.
|
|
|
|
## Consequences
|
|
|
|
- Cross-Organization data access is prevented by database credentials and
|
|
process/filesystem identity in addition to application authorization.
|
|
- Provisioning, migrations, backups, health, and upgrades are repeated per
|
|
Silo and therefore must be automated before tenant count grows materially.
|
|
- Cross-Organization fairness is not applicable inside one Silo; host cgroup
|
|
ceilings prevent one Silo from exhausting the machine.
|
|
- Database/workspace backups and the keyring/environment recovery copy are
|
|
produced to distinct protected destinations and must pass a restore drill.
|
|
|
|
## Deferred
|
|
|
|
- Shared platform identity and administration from ADR-0023.
|
|
- Pooled durable fair scheduling from ADR-0022.
|
|
- Customer org administration SPA and self-service onboarding.
|
|
- Docker or Kubernetes as an alternative deployment adapter.
|