Root cause: the application-controller renders every per-region
HelmRelease with `sourceRef.name` defaulted via env CATALOG_SOURCE_REF
(`openova-catalog`) in `flux-system`, but the chart never shipped the
matching `HelmRepository` CR. Flux's helm-controller logged
`Source 'HelmRepository/openova-catalog' not found` on every
Application reconcile; the workload Pod was never scheduled. The
qa-wp Application on qa-omantel sat at status.phase=Pending forever,
blocking ~30 qa-loop matrix TCs (TC-066/100/103/104/109/113/216/262 +
every other qa-omantel-namespaced test).
Fix (target-state per docs/INVIOLABLE-PRINCIPLES.md #1):
- New template `openova-catalog-helmrepository.yaml` ships the missing
Flux v1 HelmRepository in flux-system pointing at
`oci://ghcr.io/openova-io` with the canonical `ghcr-pull` Secret +
15m interval (matches sibling bootstrap-kit HelmRepositories).
- New values block `catalog.helmRepository.{enabled,name,namespace,
type,url,secretRef,interval}` — every field operator-overridable
per docs/INVIOLABLE-PRINCIPLES.md #4 (per-Sovereign overlays may
swing url to a local Harbor proxy_cache via the cutover-driver).
- Chart bump 1.4.128 -> 1.4.129.
Verification on fresh provision:
- `kubectl get hr -n flux-system openova-catalog` exists, Ready=True
- `kubectl get pods -n qa-omantel` shows qa-wp-* Running
- `GET /api/v1/sovereigns/.../resources/pods?ns=qa-omantel` returns
qa-wp Pod with phase=Running
- Application qa-wp.status.phase flips Pending -> Provisioning ->
Ready within 3 minutes of chart roll
- ~30 qa-omantel-namespaced TCs unblock (TC-066/100/103/104/109/113/
216/262 + cohorts)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
c139dd00fb