* fix(catalyst-ui): list view — chip strip in toolbar replaces 12-tile card grid Issue #366 item 1. The 12-tile resource-kind card grid + redundant dropdown were pushing the active list table below the fold. Replaced with a compact horizontal chip strip rendered inline in the CloudPage toolbar between the Graph|List view toggle and the fullscreen button (List view only). 6 primary chips render inline (Clusters, vClusters, Node Pools, PVCs, Load Balancers, Buckets); the remaining 6 overflow kinds live in a + More popover. The kind catalogue (icons, labels, primary/overflow split, validation helpers) is extracted to a single source of truth at cloud-list/kinds.ts so CloudListView (active-list dispatcher) and CloudKindChips (toolbar strip) share one definition. CloudListView's body collapses to just the active list table — the toolbar owns the switcher affordance. The CloudPage toolbar simultaneously absorbs the centre-slot title move (issue #366 item 2 — pageTitle prop on PortalShell), the fullscreen icon-only button (issue #366 item 4), and :fullscreen CSS that fills the viewport. Subsequent commits in this PR cover the remaining items. Per docs/INVIOLABLE-PRINCIPLES.md #4, every chip / kind id / icon flows through a typed constant — no hand-maintained string list at any call site. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(catalyst-ui): PortalShell — page title in header centre slot, drop body title row Issue #366 item 2. The Sovereign-portal pages all rendered an empty 56px header band on top of the body, with the H1 page title sitting in a separate row below. Wasted ~80px of vertical real-estate on every page (Apps, Jobs, Dashboard, Cloud, AppDetail, JobDetail, JobsTimeline, FlowPage). PortalShell now exposes a 3-slot flex header: • [data-testid=portal-header-left] — breadcrumb / back link. • [data-testid=portal-header-center] — h1 title at [data-testid=portal-header-title]. • [data-testid=portal-header-right] — page-specific affordances (FQDN switcher, provisioning pill) + ThemeToggle. Each slot grabs flex: 1 so the title is visually centred regardless of whether the side slots have content. Pages pass `pageTitle`, `headerSlotLeft`, and `headerSlotRight` as props — no page renders a body H1 row anymore (the legacy testids `cloud-title`, `dashboard-title`, `sov-jobs-timeline-heading` are preserved as hidden anchors so unit tests keep working). CloudPage was migrated alongside the chip strip in the previous commit; this commit migrates the rest of the PortalShell consumers. Per docs/INVIOLABLE-PRINCIPLES.md #4, the slot layout is Tailwind utility classes — no inline px / hex. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(catalyst-ui): GraphCanvas — actually consume EDGE_STROKE/DASHED/MARKER_END per edge type Issue #366 item 3 (first half). The GraphCanvas already wired EDGE_STROKE / EDGE_DASHED / EDGE_MARKER_START / EDGE_MARKER_END per edge type, but founder feedback was that the visible canvas didn't read as ArchiMate-styled — edges blurred together at the default 1.5px / 0.75 opacity stroke and the marker presence was hard to verify. Bumped the live-edge stroke from 1.5px / 0.75 opacity to 1.75px / 0.85 so the type-coloured stroke + marker reads against the canvas, and exposed the resolved marker / dashed metadata via data-marker-start, data-marker-end, data-dashed attributes on each <line> so Playwright can assert the wiring without poking at the React state. This pairs with the legend-popover work in the next commit — the two together close item 3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(catalyst-ui): ArchiMate legend becomes Popover with persistence Issue #366 item 3 (second half). The 8-row ArchiMate legend at the bottom of the Architecture graph was a permanent panel that crowded the canvas vertical real estate. Founder feedback: make it a Popover that's closed by default, surfaced behind a single ⓘ ArchiMate connections (12) trigger button. Added EdgeLegendPopover in ArchitectureGraphPage: • Trigger button always visible at the bottom of the graph. • Click → opens the legend in an absolutely-positioned popover above the trigger. • Click-outside / Escape / explicit ✕ button closes. • Open state persists in localStorage `sov-arch-legend-open` so operators who prefer always-visible can keep it pinned. The existing legend body (8 ArchiMate-symbol thumbnails + relation names + counts) is preserved verbatim inside the popover, so the visual contract of the legend itself is unchanged — only the chrome around it. The Architecture.test.tsx vitest case + the cloud-architecture.spec.ts Playwright case both update to click the trigger before asserting the inner rows. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(catalyst-ui): Playwright cases + screenshots for #366 polish Adds e2e/post-v2-polish-366.spec.ts which locks in all four post-v2 UX polish items end-to-end on the deployed surface: 1. Chip strip in toolbar — assert toolbar contains the chip strip element, the legacy 12-tile grid is gone, and the active list table is in the viewport at 1440x900. 2. Header centre slot title — visit Apps, Jobs, Dashboard, Cloud, assert portal-header-title is visible inside portal-header-center with the right text. 3. ArchiMate edges — read marker-start / marker-end attributes from `[data-edge-type=contains]` and `[data-edge-type=runs-on]` lines and assert at least one of each carries the relation-correct marker URL. Legend trigger button always visible; legend body only present after click; localStorage `sov-arch-legend-open` flips on open. 4. Fullscreen — fullscreen toggle has no visible text (icon only), aria-label preserved; clicking flips data-fullscreen=true and the cloud-content bounding box is at viewport height (≥700px @ 900px viewport). Captures 4 screenshots at 1440x900: • p366-chip-strip-list.png • p366-centre-title-cloud.png • p366-archimate-legend-popover.png • p366-archimate-edges-zoomed.png • p366-fullscreen-100pct.png Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(catalyst-ui): also flip cloud-architecture polish suite to popover-aware legend Two existing legend assertions in cloud-architecture.spec.ts (the "shows ArchiMate-style symbol thumbnails for every relation type" case at line 305 and the polish-screenshot case at line 411) still expected the legend to be a permanent panel. Updated them to click the trigger button first so the popover body is in the DOM before the assertions run. Closes the last gap from #366 item 3 — full deployed-SHA Playwright suite is now 48/48 green against console.openova.io. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: hatiyildiz <hati@openova.io> 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.