openova/openova
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity
b52fc45c37
openova/products/catalyst
History
e3mrah b52fc45c37
fix(bp-catalyst-platform): cutover-driver RBAC dual-mode render (#830) (#839) 
Chart 1.3.2 shipped serviceaccount-cutover-driver.yaml +
clusterrole-cutover-driver.yaml + clusterrolebinding-cutover-driver.yaml
with `{{ .Release.Namespace }}` directives that rendered fine via Helm
on Sovereigns but BROKE the Kustomize-mode contabo-mkt deploy: the
directives made Kustomize parse the files as invalid YAML and silently
skip them. Worse, the new files were never added to templates/
kustomization.yaml's resources list.

Result on contabo: catalyst-api Pod's spec.serviceAccountName references
a non-existent SA — the Pod fails ContainerCreating with the same RBAC
forbidden error #830 was meant to fix.

Fix:
  - Strip `{{ .Release.Namespace }}` directives from the SA + ClusterRole
    files. metadata.namespace auto-fills from Helm's --namespace flag
    and from Kustomize's `namespace:` directive.
  - For ClusterRoleBinding: Helm does NOT auto-inject subjects[0].
    namespace the way it does metadata.namespace, so the apiserver
    rejects bindings without it. Split into two files:
      * clusterrolebinding-cutover-driver.yaml — Helm-only, uses
        {{ .Release.Namespace }} (correctly resolves to catalyst-system
        on Sovereigns).
      * clusterrolebinding-cutover-driver-kustomize.yaml — Kustomize-
        only, omits subjects[0].namespace and relies on Kustomize's
        native injection (resolves to `catalyst` on contabo).
    The .helmignore excludes the Kustomize-only file from Sovereign
    chart packaging; templates/kustomization.yaml's resources list
    references the Kustomize-only file, NOT the Helm-only one.
  - Add the new RBAC files to templates/kustomization.yaml's resources
    list so contabo's Flux Kustomization actually renders them.

Verified live with `helm template` (subjects[0].namespace=catalyst-system)
and `kubectl kustomize` (subjects[0].namespace=catalyst).

Bumps bp-catalyst-platform 1.3.2 → 1.3.3.

Issue: openova-io/openova#830 (Bug 1 follow-up)

Co-authored-by: hatiyildiz <hatice.yildiz@openova.io>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-04 23:54:03 +04:00
..
bootstrap feat(sme-tenant): multi-domain Sovereign support — parent-domain dropdown + free-subdomain-under-any-pool-domain (#828) (#836) 2026-05-04 23:48:10 +04:00
chart fix(bp-catalyst-platform): cutover-driver RBAC dual-mode render (#830) (#839) 2026-05-04 23:54:03 +04:00
README.md feat(consolidation): Phase 1 — move Catalyst-Zero apps + CI + manifests into public monorepo 2026-04-28 12:08:09 +02:00

README.md

OpenOva Catalyst (composite Blueprint)

The umbrella Blueprint bp-catalyst-platform — composes the Catalyst control plane.

Status: Deployed. Updated: 2026-04-28.

This product directory contains:

  • chart/ — the Helm chart that deploys Catalyst-Zero on a Kubernetes cluster (and every franchised Sovereign).
  • chart/templates/{ui,api}-deployment.yaml + service + ingress — the catalyst-ui (React SPA wizard scaffold) and catalyst-api (Go bootstrap API) workloads.
  • chart/templates/sme-services/ — 11 manifests for the legacy SME backend services + the consolidated console, admin, marketplace UI workloads (sourced from core/{console,admin,marketplace}/).
  • chart/templates/marketplace-api/ — manifests for the Go marketplace-api backend (sourced from core/marketplace-api/).
  • bootstrap/{ui,api}/ — the source code for catalyst-ui and catalyst-api (deployed via the catalyst-build CI workflow).

For the unified architecture and the wizard's target shape, see docs/PROVISIONING-PLAN.md, docs/ARCHITECTURE.md, and docs/SOVEREIGN-PROVISIONING.md.

How Catalyst-Zero is deployed today

A Flux Kustomization on the Catalyst-Zero cluster (Contabo k3s) reconciles products/catalyst/chart/templates/ from this public repo. CI workflows (.github/workflows/{catalyst,console,admin,marketplace,marketplace-api}-build.yaml) build and push images on every push to main, then the deploy step pins the image SHA into the corresponding manifest in this directory and commits back. Flux picks up the commit and rolls the deployment.

Image registry: ghcr.io/openova-io/openova/{catalyst-ui,catalyst-api,console,admin,marketplace,marketplace-api}:<sha>.

Migration status (per docs/PROVISIONING-PLAN.md)

Component Source location Image Status
catalyst-ui products/catalyst/bootstrap/ui/ ghcr.io/openova-io/openova/catalyst-ui ✅ public repo
catalyst-api products/catalyst/bootstrap/api/ ghcr.io/openova-io/openova/catalyst-api ✅ public repo
console core/console/ ghcr.io/openova-io/openova/console ✅ public repo (Phase 1)
admin core/admin/ ghcr.io/openova-io/openova/admin ✅ public repo (Phase 1)
marketplace core/marketplace/ ghcr.io/openova-io/openova/marketplace ✅ public repo (Phase 1)
marketplace-api core/marketplace-api/ ghcr.io/openova-io/openova/marketplace-api ✅ public repo (Phase 1)
sme-{auth,billing,catalog,domain,gateway,notification,provisioning,tenant} (still in openova-private/services/) ghcr.io/openova-io/openova-private/sme-* ⏳ follow-up phase — source not yet moved