Self-hosted clone of https://github.com/openova-io/openova (post-cutover, standalone)
aed0a81f75
* fix(catalyst-api): rip out dangling sovereign_* route registrations + chart 1.4.56 PR #1050 deleted sovereign_more.go (which defined HandleSovereignUsers, HandleSovereignCatalog, HandleSovereignSettings, HandleSovereignTopology) but left four route registrations in cmd/api/main.go that still referenced those handler methods. The catalyst-api build for the merged revert (run 25439549879) failed with: cmd/api/main.go:690:39: h.HandleSovereignUsers undefined cmd/api/main.go:691:41: h.HandleSovereignCatalog undefined cmd/api/main.go:692:42: h.HandleSovereignSettings undefined cmd/api/main.go:693:42: h.HandleSovereignTopology undefined That's why ghcr.io/openova-io/openova/catalyst-api:fdd3354 was never published — only the UI image rolled. Result: omantel.biz catalyst-api pod stuck in ImagePullBackOff. Drop the four route registrations. Same baby, new address — the chroot Sovereign uses the existing /api/v1/deployments/{depId}/* handlers via the JWT-resolved deploymentId, not parallel-baby /api/v1/sovereign/* endpoints. Also revert two more parallel-baby fragments still on main: - getHierarchicalInfrastructure mode-aware fetcher → single mother URL (the chroot resolves deploymentId from the cookie and the mother-side topology handler serves byte-identical data once cutover-import has persisted the deployment record on the Sovereign's local store) - CatalogAdminPage.fetchApps mode-aware → /catalog/apps everywhere Bump bp-catalyst-platform chart 1.4.55 → 1.4.56 and the cluster Kustomization version pin to match. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(sovereignDynamicClient): in-cluster fallback when running ON the Sovereign The chroot Sovereign Console at console.<sov-fqdn> is the SAME catalyst-api binary as the mother. When that binary runs ON the Sovereign cluster (catalyst-system namespace on the Sovereign itself), there is no posted-back kubeconfig — the catalyst-api IS in the cluster it needs to talk to, and rest.InClusterConfig() returns the right credentials. Without this, every endpoint that needs the Sovereign-side dynamic client returned 503 with "sovereign cluster kubeconfig not yet posted back" — including ListUserAccess (/users page), CreateUserAccess, infrastructure CRUD, etc. Caught on omantel.biz 2026-05-06: /users rendered "list user-access: HTTP 503" because the Sovereign-side catalyst-api was looking for a kubeconfig that doesn't exist on the chroot side of the cutover boundary. Detection: SOVEREIGN_FQDN env (set on every Sovereign-side catalyst-api deployment by the chart) matches dep.Request.SovereignFQDN. On the mother, SOVEREIGN_FQDN is unset → unchanged behavior. On the chroot, SOVEREIGN_FQDN matches the only deployment served (its own) → use in-cluster. Same fallback applied to tryDynamicClientLocked (loaderInputFor's best-effort live-source client) so /infrastructure/topology and the /cloud graph render with live data on the chroot too. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(user-access): empty list when CRD absent + RBAC for chroot Two coupled fixes for the /users page on chroot Sovereign Console: 1. catalyst-api-cutover-driver ClusterRole: grant read/write on useraccesses.access.openova.io. The Sovereign chroot's catalyst-api uses the in-cluster ServiceAccount (per PR #1052). The list call was returning 403 from the apiserver because the SA had no rule covering this CRD. 2. ListUserAccess: return 200 with empty items when the CRD itself is not installed (apierrors.IsNotFound). The access.openova.io CRD ships via a separate blueprint that may not yet be installed on a fresh Sovereign — the page should render its empty state, not a 500 toast. Caught live on omantel.biz 2026-05-06 after PR #1052 unblocked the in-cluster client path: list call surfaced first as 403 (RBAC), then as 500 "server could not find the requested resource" (CRD absent). Both now resolve to a 200 + []. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(chroot): byte-identical /jobs + /cloud — kill fixture fallback, lazy-seed jobs.Store from live cluster, single endpoint Two parallel-baby paths still made the chroot diverge from the mother on /cloud and /jobs/{jobId}. Both now ship one path that serves byte-identical data on both surfaces. 1. CloudPage rendered fictional topology (Frankfurt, Helsinki, omantel-primary, omantel-secondary, edge-lb, vpc-net-eu, …) when the topology query errored — because it fell back to `infrastructureTopologyFixture` from `src/test/fixtures/`. That is a test-only file leaking into production via the production import tree, in direct violation of INVIOLABLE-PRINCIPLES #1 (no placeholder data — empty state when you don't know). Fix: drop the fixture fallback. On error → null → empty-state render. The mother shows the same empty state when its loader returns nothing; byte-identical. 2. JobsTable + JobDetail rendered a flat green-grid because the chroot was hitting `/api/v1/sovereign/jobs` which returns a minimal shape (no dependsOn, no parentId, no exec records). Mother's `/api/v1/deployments/{depId}/jobs` returns the rich shape from a per-deployment jobs.Store, which on the chroot starts empty (the mother's exportDeploymentToChild only ships the deployment record, not the jobs.Store contents). Fix: ship one URL on both surfaces — `/api/v1/deployments/{id}/jobs`. Add `chrootSeedJobsStoreIfEmpty` that runs at handler-time when SOVEREIGN_FQDN matches dep.Request.SovereignFQDN AND the per- deployment jobs.Store has 0 records: do a one-shot HelmRelease list via the in-cluster client (helmwatch.ListAndSnapshotHelmReleases — exported here, mirrors Watcher.SnapshotComponents without spinning up an informer), pass through snapshotsToSeeds + Bridge.SeedJobsFromInformerList. Subsequent calls read directly from the now-populated store and return rich Job records with dependsOn / parentId / status — exactly like the mother. useLiveJobsBackfill loses its mode-aware fetcher; the chroot UI uses the same `/api/v1/deployments/{id}/jobs` URL as the mother. 3. HandleDeploymentImport now also loads the imported record into the in-memory deployments map immediately, so `/deployments/{id}/*` handlers don't need a pod restart's restoreFromStore to see the chroot-imported deployment. Bump bp-catalyst-platform 1.4.56 → 1.4.57 (chart + Kustomization). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(jobdetail): bare-jobName URL — Traefik strips %3A so canonical id 404s JobDetail navigation was 404ing on the chroot because the link builder URL-encoded the canonical Job id ("69e73b3abe673840:install-keycloak") and Traefik (or any upstream proxy that's RFC 3986 §3.3-strict) does not decode `%3A` inside path segments. The catalyst-api router saw the literal "%3A" and Store.GetJob's exact-match path missed. Two coupled fixes: 1. useJobLinkBuilder strips the "<deploymentId>:" prefix before encoding, producing /jobs/install-keycloak (Traefik-safe) instead of /jobs/69e73b3abe673840%3Ainstall-keycloak. Store.GetJob already accepts both bare jobName and canonical id (see store.go:781-789). 2. JobDetail.jobsById indexes by BOTH canonical id AND bare jobName so the URL param resolves regardless of which format the link emitted. Bump chart 1.4.58 → 1.4.59. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cloud): resolve deploymentId from cookie on chroot — was firing topology against undefined CloudPage's topology query fired against /deployments/undefined/... on the chroot (URL is /cloud, no deploymentId path segment), so the page showed "Couldn't load architecture" with all node counts at 0/0. Fix: same pattern as JobDetail — useResolvedDeploymentId() reads the JWT cookie's deployment_id claim via /api/v1/sovereign/self, falling back from URL params. Topology query also gates on `!!deploymentId` so it doesn't waste a 404 round-trip during cookie resolution. Bump chart 1.4.60 → 1.4.61. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(chroot): single chrome — no frame in frame, no mother handover banner Two visible bleed-throughs from the mother's wizard UX onto the chroot Sovereign Console at console.<sov-fqdn>: 1. **Two stacked headers + sidebar inside sidebar** ("frame in frame"). SovereignConsoleLayout rendered its own sidebar+header AND the page inside rendered PortalShell which rendered ANOTHER header (its sidebar was already skipped for chroot per a prior fix). User saw two horizontal title bars stacked. Resolution: SovereignConsoleLayout becomes auth-only on the chroot. It runs the cookie/OIDC auth gate + RequiredActionsModal, then renders <Outlet/> with NO chrome. PortalShell is now the single chrome owner on both surfaces: - Mother (/sovereign/provision/$id): renders Sidebar with /provision/$id/X URLs + its header. - Chroot (console.<sov-fqdn>): renders SovereignSidebar with clean /X URLs + the same header. One sidebar, one header, byte-identical to mother layout. 2. **"✓ Sovereign is ready — Redirecting to your Sovereign console" banner on /apps.** This is the mother's wizard celebration that tells the operator "you can now jump to your new Sovereign". On the chroot the operator IS already on the Sovereign Console; the banner bleeds through because the imported deployment record carries the mother's handover-ready event in its history. Resolution: AppsPage gates the banner, the toast, and the auto-redirect timer on `!isSovereignMode`. Chroot stays clean. Bump chart 1.4.62 → 1.4.63. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(chroot): wrap chroot-only pages in PortalShell + drop /catalog page Three chroot-only pages bypassed PortalShell entirely. After SovereignConsoleLayout went auth-only in #1057, they rendered full-bleed with no sidebar / no header — visible look-and-feel break. /settings/marketplace → MarketplaceSettings (wrapped in PortalShell) /parent-domains → ParentDomainsPage (wrapped in PortalShell) /catalog → CatalogAdminPage (deleted) Drop /catalog entirely per founder direction: a separate page just to flip a "publish to marketplace" boolean per app is the wrong shape. The natural place for that toggle is on each /apps card (future PR — needs HandleSovereignApps to join publish state from the SME catalog microservice). Removed: - /catalog route registration in router.tsx - 'Catalog' entry in SovereignSidebar's FLAT_NAV - CatalogAdminPage.tsx (525 lines) - 'catalog' from ActiveSection union + deriveActiveSection regex The publish-state PATCH endpoint at /catalog/admin/apps/{slug}/publish on the SME catalog service is unaffected; it's exposed at marketplace.<sov-fqdn>, not console.<sov-fqdn>, and the future apps-card toggle will call it via the same path. Bump chart 1.4.64 → 1.4.65. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .claude | ||
| .github | ||
| .playwright-mcp | ||
| clusters | ||
| core | ||
| docs | ||
| infra/hetzner | ||
| platform | ||
| products | ||
| scripts | ||
| tests | ||
| .gitignore | ||
| CLAUDE.md | ||
| README.md | ||
OpenOva Catalyst
A self-sufficient Kubernetes-native platform. Published as signed OCI Blueprints. Deployable as your own Sovereign.
Catalyst is the open-source platform built by OpenOva. It turns any Kubernetes cluster into a Sovereign: a self-contained control plane that hosts Organizations, Environments, and Applications via GitOps + Crossplane, with a unified UI/Git/API for users.
Documentation
| Document | What it covers |
|---|---|
docs/GLOSSARY.md |
Canonical terminology — read first |
docs/ARCHITECTURE.md |
Catalyst architecture overview |
docs/IMPLEMENTATION-STATUS.md |
What's built today vs what's design-only — read second |
docs/NAMING-CONVENTION.md |
Naming patterns for every resource type |
docs/PERSONAS-AND-JOURNEYS.md |
Personas × journeys matrix; surfaces |
docs/SECURITY.md |
Identity (SPIFFE + Keycloak), secrets (OpenBao + ESO), rotation, multi-region semantics |
docs/SOVEREIGN-PROVISIONING.md |
How to bring a Sovereign online |
docs/BLUEPRINT-AUTHORING.md |
Writing Blueprints (incl. Crossplane Compositions) |
docs/PLATFORM-TECH-STACK.md |
Every component's role in Catalyst |
docs/SRE.md |
Operating a Sovereign |
docs/BUSINESS-STRATEGY.md |
Product strategy and GTM |
docs/TECHNOLOGY-FORECAST-2027-2030.md |
Component forecast 2027–2030 |
docs/VALIDATION-LOG.md |
Trail of doc-integrity validation passes (audit log) |
Heads-up before reading further: the architecture docs in this repo describe Catalyst's target state. Significant portions are not yet implemented — see
docs/IMPLEMENTATION-STATUS.mdfor what exists today vs what is design.
The model in 60 seconds
OpenOva (the company) publishes Catalyst (the platform).
A deployed Catalyst is called a Sovereign.
A Sovereign has:
- Organizations (multi-tenancy unit)
- Environments (org-scoped, env-typed: prod/stg/uat/dev/poc)
- Applications (installed Blueprints)
- Blueprints (the App Store catalog — public + Org-private)
Users install Applications from Blueprints into Environments.
Blueprints can depend on Blueprints (arbitrary depth).
Each Environment is one Gitea repo + one or more vclusters.
Every state change is a Git commit.
Every UI surface reads from a single CQRS projection.
Same code runs in every Sovereign:
- openova (run by us; SaaS Organizations)
- omantel (run by Omantel; SME Organizations across Oman)
- bankdhofar (run by the bank; internal Organizations)
- your-company (run by you, on infrastructure you choose)
See docs/GLOSSARY.md for every term, docs/ARCHITECTURE.md for the full picture.
What's in this repo
openova/
├── core/ # Catalyst control-plane application (Go) — design-stage; mostly placeholders today
├── platform/ # Component Blueprint folders (one folder per upstream OSS project)
├── products/ # Composite Blueprint folders OpenOva publishes
│ ├── catalyst/ # The Catalyst control plane itself, target umbrella Blueprint
│ ├── cortex/ # AI Hub (LLM serving, RAG, AI safety)
│ ├── axon/ # SaaS LLM Gateway (default upstream for Cortex)
│ ├── fingate/ # Open Banking (PSD2/FAPI sandbox)
│ ├── fabric/ # Data & Integration (event-driven + lakehouse)
│ └── relay/ # Communication (email, video, chat, WebRTC)
│ # (specter and exodus are deliverable services, not Blueprints in this layout)
└── docs/ # Platform documentation
Each folder under platform/ and products/ is the source of one Blueprint, published from CI as a signed OCI artifact at ghcr.io/openova-io/bp-<name>:<semver> (the bp- prefix is added to the OCI artifact name; folder names stay short). Per-folder isolation is provided at the OCI artifact layer, not the Git repo layer — this is a monorepo with per-Blueprint fan-out, not a meta-repo of separate Git repositories. See docs/BLUEPRINT-AUTHORING.md §2 for the folder layout contract.
Today, the 12-component bootstrap kit (cilium, cert-manager, flux, crossplane, sealed-secrets, spire, nats-jetstream, openbao, keycloak, gitea, powerdns + the bp-catalyst-platform umbrella under
products/catalyst/) ships with fullchart/+blueprint.yamlperdocs/IMPLEMENTATION-STATUS.md§7, plusproducts/axon/and theexternal-dnsleaf chart. The remaining 45 platform components and thecortex / fabric / fingate / relayproduct folders are design-stage — README only — until each lands its Blueprint manifest, chart, Compositions, and CI fan-out.
Stack at a glance
| Layer | Technology |
|---|---|
| Container runtime | k3s (k8s-conformant), containerd |
| CNI / Service Mesh | Cilium (eBPF mTLS, L7 policies, Gateway API) |
| GitOps | Flux (per-vcluster, lightweight) |
| Git | Gitea (per-Sovereign, hosts Blueprint mirror + per-Environment repos) |
| IaC for non-K8s | Crossplane (the only IaC; not user-facing) |
| Bootstrap IaC | OpenTofu (one-shot, archived after Phase 0) |
| Multi-tenancy | vcluster (one per Organization per host cluster) |
| Identity (workloads) | SPIFFE/SPIRE (5-min rotating SVIDs, mTLS everywhere) |
| Identity (users) | Keycloak (per-Org for SME, per-Sovereign for corporate) |
| Secrets | OpenBao (Apache 2.0; independent Raft per region, no stretched cluster) + External Secrets Operator |
| Event spine | NATS JetStream (Apache 2.0; pub/sub + KV; per-Org accounts) |
| TLS | cert-manager + Let's Encrypt or corporate CA |
| Policy | Kyverno |
| Supply chain | cosign (Sigstore), Syft + Grype SBOM, Trivy scans |
| Runtime security | Falco (eBPF) |
| Observability | OpenTelemetry → Grafana stack (Alloy + Loki + Mimir + Tempo) |
| WAF | Coraza (OWASP CRS) |
| DNS | PowerDNS authoritative per Sovereign zone + DNSSEC + lua-records (ifurlup, pickclosest); pool-domain-manager allocates pool subdomains and flips parent-zone NS via registrar adapters (Cloudflare / Namecheap / GoDaddy / OVH / Dynadot) — see docs/MULTI-REGION-DNS.md, docs/PLATFORM-POWERDNS.md |
| Backup | Velero (to SeaweedFS, which routes the cold tier to cloud archival S3) |
| Container registry | Harbor |
For the full component list and trends see docs/PLATFORM-TECH-STACK.md and docs/TECHNOLOGY-FORECAST-2027-2030.md.
Cloud providers
| Provider | Status |
|---|---|
| Hetzner Cloud | Available (most-tested path) |
| AWS / GCP / Azure | Crossplane providers available; full path coming |
| Oracle Cloud (OCI) | Crossplane provider available; full path coming |
| Huawei Cloud | Crossplane provider available; full path coming |
All providers reach Catalyst via the same Crossplane abstraction; Sovereign provisioning details per provider are in docs/SOVEREIGN-PROVISIONING.md.
Getting started
Try it (managed)
Visit marketplace.openova.io to install Applications on the openova Sovereign without any infrastructure setup. SaaS journey for SMEs and evaluations.
Run your own Sovereign
1. Provision via catalyst-provisioner.openova.io (managed bootstrap), OR
2. Self-host bp-catalyst-provisioner in your own infrastructure (air-gap path).
Then follow the procedure in docs/SOVEREIGN-PROVISIONING.md.
Build a Blueprint
See docs/BLUEPRINT-AUTHORING.md. A Blueprint is a folder under platform/<name>/ (or products/<name>/) in this monorepo containing blueprint.yaml + manifests (Helm chart or Kustomize base) + (optional) Crossplane Compositions. CI signs each folder's contents and publishes to OCI as ghcr.io/openova-io/bp-<name>:<semver>. Catalyst's blueprint-controller picks it up automatically. Org-private Blueprints follow the same shape inside per-Sovereign Gitea repos.
License
All Blueprints and the Catalyst control plane are open source. Each component carries its own upstream license (typically Apache 2.0, MPL 2.0, or BSD-3); see each component's LICENSE file.
OpenOva charges for support, managed operations, and expert services — never for access to code. See docs/BUSINESS-STRATEGY.md §10.
Contributing
PRs welcome. The contribution path for Blueprints (including Crossplane Compositions) is documented in docs/BLUEPRINT-AUTHORING.md §13. Issues and discussions on GitHub.
Cloud-native is the foundation. Catalyst is how you operate it.