platform/orca-platform

Fork 0

Files

T

Sharang Parnerkar 8971152da0

ci / shared (pull_request) Successful in 23s

Details

ci / validate (pull_request) Successful in 4s

Details

refactor(iac): cluster split — 1 cluster per plane, breakpilot-* naming

Restructures the draft to reflect the 2026-06-30 cluster decision:

Three Orca clusters, each becoming its own Gitea repo at migration time:
- breakpilot-edge   → vm-edge       (Identity + Infra: KC, Gitea, Infisical, PowerDNS, Orca-Proxy)
- breakpilot-control → vm-control   (Portal, tenant-registry, ERPNext, MariaDB, Stalwart)
- breakpilot-app    → vm-app-prod + vm-app-stage (CERTifAI, compliance-*, Mongo, MinIO, Qdrant, LiteLLM)

Key model points encoded:
- Identity (Keycloak) co-tenant with Infra on vm-edge (1 VM core), per
  INFRASTRUCTURE.md §6 — heap pinned so it cannot starve PowerDNS/Infisical
- Stage and prod live in the same breakpilot-app cluster on different
  VMs. Stage authenticates via prod Keycloak under tenant.kind = "stage";
  no duplicated identity, no duplicated control plane (per §5).
- The existing CERTifAI Keycloak will be repurposed for breakpilot-edge
  rather than standing up a fresh one — same realm, same users.
- Multi-VM rollout gated on legal entity being established so we can sign
  SysEleven / Hetzner business contracts. Until then, single-VM ops
  continues via ~/workspace/orca-infra; this repo is design-only.

Mechanical changes:
- manifests/{vm-edge,vm-control,vm-data,stage}/ → clusters/{breakpilot-edge,breakpilot-control,breakpilot-app/services/{prod,stage}}/services/
- vm-data → vm-app-prod, stage → vm-app-stage in node references and headers
- overlays/{stage,prod}/overlay.toml point at the new cluster paths
- scripts/validate.sh now enforces a per-cluster node whitelist
  (breakpilot-edge → vm-edge, breakpilot-control → vm-control,
  breakpilot-app → {vm-app-prod, vm-app-stage}) instead of dir-name equality
- New READMEs at clusters/, clusters/breakpilot-edge/,
  clusters/breakpilot-control/, clusters/breakpilot-app/ documenting
  scope, SLA targets, co-tenant notes, and the future-repo split
- Top README rewritten to lead with the cluster-split decision and the
  legal-entity gate; per-milestone fill-in table re-pathed

Validation:
- make validate → 38 files OK (35 manifests + 3 overlays)
- make plan ENV=stage → 11 resolved manifests in .orca-out/stage/
- make plan ENV=prod  → 24 resolved manifests in .orca-out/prod/

2026-06-30 22:14:51 +02:00

3.3 KiB

Raw Blame History

breakpilot-app

App plane (formerly "Data plane" in the May 18 doc). Two VMs in one cluster:

vm-app-prod — production workloads, customer data, real keys
vm-app-stage — staging workloads, demo data, sandbox tenant

Becomes its own Gitea repo platform/breakpilot-app at migration time.

Services

Prod (`services/prod/`, 9 services)

Service	Purpose
`admin-compliance.toml`	Compliance back-office admin
`ai-compliance-sdk.toml`	LLM-mediated compliance SDK
`backend-compliance.toml`	Compliance scanner backend
`certifai-dashboard.toml`	CERTifAI dashboard (first product)
`litellm.toml`	LLM gateway
`minio.toml`	S3-compatible object store
`mongodb.toml`	Compliance + CERTifAI data
`pg-app.toml`	Per-tenant application Postgres (SPOF — RISK-1 in `§7`)
`qdrant.toml`	Vector store (rebuildable)

Stage (`services/stage/`, 11 services)

Service	Purpose
`admin-compliance.toml`	Stage admin
`ai-compliance-sdk.toml`	Stage SDK
`backend-compliance.toml`	Stage backend
`certifai-dashboard.toml`	Stage CERTifAI
`customer-portal.toml`	Stage portal (calls prod KC + prod tenant-registry with `tenant.kind = "stage"`)
`litellm.toml`	Stage LLM gateway (may reuse prod)
`mongodb-stage.toml`	Stage Mongo
`orca-proxy.toml`	Per-node ingress on `vm-app-stage`
`pg-app-stage.toml`	Stage Postgres
`qdrant-stage.toml`	Stage vector store
`tenant-registry.toml`	(placeholder; stage calls prod registry — manifest exists for parity)

SLA targets (per `INFRASTRUCTURE.md §6`)

Owns:    DATA_RESIDENCY — all customer data (MongoDB, pg-app, MinIO) must stay EU
         RPO (product)  — compliance records ≤ 6h; chat history ≤ 24h
         DATA_ISOLATION — every query scoped by org_id / tenant_id
         AUDIT_TRAIL    — product-level actions
         AVAILABILITY   — CERTifAI ≥ 99.5%; compliance ≥ 99.5%

Why one cluster, two VMs

Same orca-platform config, different physical workloads. Stage and prod don't drift on infra config because they're in the same cluster.
No "oops touched prod" accidents. Per-service placement.node pins which VM each container lands on; prod manifests live in prod/, stage in stage/.
Blast radius is physical. A stage misconfiguration cannot exhaust vm-app-prod's memory because they share nothing but the Orca control socket.

Stage isolation contract

Stage services never:

email real customers (Stalwart accept-rule on breakpilot-control drops recipients not matching *+stage@*)
trigger real Polar charges (POLAR_API_URL points at sandbox)
carry real customer data (sandbox tenant resets nightly)

Stage services always:

authenticate via prod Keycloak with tenant.kind = "stage"
read tenant config from prod tenant-registry (read-only for stage tenants)
expose *.stage.breakpilot.com (or whatever the staging subdomain is)

See INFRASTRUCTURE.md §5 for the full stage-prod sharing contract.

Sandbox tenant

The sandbox tenant in stage/ is the only place that accepts writes from public demo visitors. A nightly cron (lands as sandbox-reset.toml when seed-data fixtures are wired in M13.1) resets its Mongo collections and Keycloak user attributes from a versioned seed.

3.3 KiB Raw Blame History