Self-hosted clone of https://github.com/openova-io/openova (post-cutover, standalone)
Go to file
e3mrah 855e106d87
fix(bp-cnpg): wait for webhook readiness so downstream Cluster CRs don't race (#1450)
* fix(infra): pass cp_private_ip to primary CP templatefile too

PR #1446 added cp_private_ip references in cloudinit-control-plane.tftpl
but only the SECONDARY templatefile call at main.tf:840 already had
that var threaded. The PRIMARY CP call at line 342 was missed and
tofu plan blew up with "vars map does not contain key cp_private_ip".

Set it to "10.0.1.2" for the primary (the hardcoded value the chart
default + worker_cloud_init already use for the canonical 10.0.1.0/24
primary subnet).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(hetzner): pass cp_private_ip into secondary-region CP cloud-init templatefile

prov #52-54 all failed at `tofu plan` once cloudinit-control-plane.tftpl
started consuming ${cp_private_ip} (PR #1446):

    Invalid value for "vars" parameter: vars map does not contain key
    "cp_private_ip", referenced at ./cloudinit-control-plane.tftpl:657,30-43.

The primary CP templatefile call (main.tf:342) and the secondary WORKER
templatefile call (main.tf:944) both pass `cp_private_ip`, but the
secondary CP templatefile call (main.tf:860) was missed — every
multi-region provision since PR #1446 lands here at plan-time.

Fix: thread `cp_private_ip = local.secondary_region_cp_ips[k]` into the
secondary CP templatefile so each secondary region's cilium-operator
reaches its OWN local CP (matching CA), not the primary across regions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(bp-cilium 1.3.4): kubeProxyReplacement true (BPF masq needs NodePort)

Worker cilium-agent on prov #55 (8d85a64cb8807cdc, 2026-05-12) crashloops:

  fatal: failed to start: daemon creation failed: unable to initialize
  BPF masquerade support: BPF masquerade requires NodePort
  (--enable-node-port="true")

Chart default kubeProxyReplacement=false leaves enable-node-port=false in
the rendered cilium-config ConfigMap. Combined with bpf.masquerade=true
(also default-on) the cilium-agent rejects the BPF masquerade datapath
on startup. CP cilium-agent survives because it was started by cloudinit
with the working pre-Flux values BEFORE Flux's helm-upgrade rolled the
ConfigMap. Every WORKER node that joins after Flux's upgrade sees the
new (broken) ConfigMap → CrashLoopBackOff → node.cilium.io/agent-not-
ready taint persists → every post-install Job pod (keycloak-config-cli,
powerdns, mimir, openbao) stays Pending → whole bootstrap-kit chain
stalls at ~60% Ready.

Cloud-init's pre-Flux Cilium install (cloudinit-control-plane.tftpl
write_files entry /var/lib/catalyst/cilium-values.yaml) already uses
kubeProxyReplacement: true. This change aligns the Flux HR overlay with
the working pre-Flux bootstrap so the agent config never regresses when
helm-controller does its first upgrade.

Bumps bp-cilium 1.3.3 → 1.3.4 and the bootstrap-kit overlay pin to match.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(bp-cnpg): wait for webhook readiness so downstream Cluster CRs don't race

prov #55+#56 caught bp-harbor / bp-powerdns failing Helm install with:

  Internal error occurred: failed calling webhook "mcluster.cnpg.io":
  no endpoints available for service "cnpg-webhook-service"

Chain:
1. bp-cnpg install with disableWait: true → HR goes Ready immediately
   when manifests apply (operator pod still spinning up).
2. Flux releases dependents (bp-harbor, bp-powerdns) — they pass the
   dependsOn check on bp-cnpg.
3. Downstream chart renders postgresql.cnpg.io/v1.Cluster CRs.
4. cnpg mutating webhook (Service cnpg-webhook-service) has no endpoints
   yet → admission webhook call fails → Helm install fails →
   RetriesExceeded → entire DB-backed chain wedges.

Carve out the disableWait: true blanket for bp-cnpg specifically.
INVIOLABLE-PRINCIPLES #3's "event-driven install" rationale (avoid the
agent-waits-for-its-own-CRDs deadlock — see bp-cilium) does NOT apply
to CNPG: CNPG's CRDs are loaded by helm-controller BEFORE pods schedule,
so Helm-wait blocks only on pod readiness, not on a self-referencing CRD.

With this change bp-cnpg's HR stays Reconciling until cnpg-controller-
manager + cnpg-webhook-service are both rolled + Available, so Flux
dependsOn correctly gates downstream consumers behind a webhook that's
actually serving.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: e3mrah <1234567+e3mrah@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-12 22:23:04 +04:00
.claude docs(iter-1): add IMPLEMENTATION-STATUS, fix wrong-org refs, reconcile monorepo 2026-04-27 20:43:31 +02:00
.github ci(openova-flow): build openova-flow-server + adapter-flux images + sed chart tags (#1398) 2026-05-11 16:03:31 +04:00
.playwright-mcp feat(wizard): job dependencies SVG DAG + (stretch) timeline view (closes #206) (#212) 2026-04-29 21:40:43 +02:00
clusters fix(bp-cnpg): wait for webhook readiness so downstream Cluster CRs don't race (#1450) 2026-05-12 22:23:04 +04:00
core fix(chart,api,controllers,ui): qa-loop iter-11 Fix #45 — three-cluster closeout (#1265) 2026-05-10 07:26:05 +04:00
docs feat(openova-flow): catalyst-api proxy + cloud-init thread (Agent #3 — integrator, infra-side) (#1396) 2026-05-11 16:01:09 +04:00
infra fix(hetzner): pass cp_private_ip into secondary CP templatefile (multi-region prov #52-54 unblock) (#1448) 2026-05-12 20:11:23 +04:00
platform fix(bp-cilium 1.3.4): kubeProxyReplacement true (BPF masq needs NodePort) (#1449) 2026-05-12 21:05:01 +04:00
products deploy: update catalyst images to 68372d7 2026-05-12 16:13:41 +00:00
scripts feat(openova-flow): server (HTTP+SSE event router) + flux adapter (K8s informer sidecar) (#1390) 2026-05-11 15:36:54 +04:00
tests fix(bp-newapi+services-build): imagePullSecrets on Pod, sed bumps values.yaml smeTag (#955) 2026-05-05 15:47:37 +04:00
tools/qa-loop feat(qa-loop): tier-scoped test-session endpoint + canonical PW runner (iter-11 Fix #46) (#1266) 2026-05-10 07:40:44 +04:00
.gitignore feat(infra-hetzner): wire all var.regions[] entries end-to-end (slice G1, #1095) (#1131) 2026-05-09 00:29:44 +04:00
CLAUDE.md docs(component-count): update 53 → 56 anchors after Pass 105 (spire + nats-jetstream + sealed-secrets) 2026-04-28 13:48:24 +02:00
package-lock.json feat(openova-flow): npm workspaces + FlowPage canvas real-adapter rewire (Agent #5) (#1399) 2026-05-11 16:59:07 +04:00
package.json feat(openova-flow): npm workspaces + FlowPage canvas real-adapter rewire (Agent #5) (#1399) 2026-05-11 16:59:07 +04:00
README.md docs(reconcile-pass-2): align docs with ground truth at 6afdb303 2026-04-29 11:48:57 +02:00

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 20272030
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.md for 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 full chart/ + blueprint.yaml per docs/IMPLEMENTATION-STATUS.md §7, plus products/axon/ and the external-dns leaf chart. The remaining 45 platform components and the cortex / fabric / fingate / relay product 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.