Closes#149 (prov #24, c776423270f4ae30): bp-cert-manager terminal failure
"no matches for kind ClusterIssuer in version cert-manager.io/v1" — the
post-install ClusterIssuer hook (weight 5) fires before the cert-manager.io
ClusterIssuer CRD reaches status.conditions[?(@.type=="Established")].status
== "True". The upstream Jetstack subchart installs CRDs as regular templates
(no helm.sh/hook), so kubectl apply returns when the resource is CREATED —
not when the apiextensions-apiserver has finished Establishing it. Async in
the apiserver; observed up to 30s on fresh Hetzner cold-start k3s.
Target-state fix per docs/INVIOLABLE-PRINCIPLES.md #4 (no hardcoded
band-aids): a post-install,post-upgrade hook-weight -10 Job that polls
every CRD in values.crdGate.crds for Established=True. Only after the
gate exits 0 does the ClusterIssuer hook (weight 5) fire. Models the
canonical webhook-gate pattern from bp-external-secrets-stores (#137,
#143) — same SA + ClusterRole + ClusterRoleBinding + Job triplet.
300s budget gives ~10x headroom over worst-case observed Established
latency while still failing fast on a genuinely broken upstream.
Chart 1.1.2 -> 1.2.0 (minor bump: new templates + new values stanza).
HR pins in clusters/_template + clusters/omantel + clusters/otech
bumped to 1.2.0.
Per principle 16: canonical seam = the chart's templates/clusterissuer-*.yaml
post-install hook. Per principle 18: every gate knob (enabled, crds,
timeoutSeconds, intervalSeconds, image, imagePullPolicy) templatable.
## Claimed TCs
- prov #24 bp-cert-manager Ready=True (and downstream HRs that depend on
cert-manager: bp-cilium-gateway, bp-harbor, bp-gitea, bp-keycloak,
bp-openbao, bp-catalyst-platform — all unblocked once cert-manager
goes Ready)
Co-authored-by: openova-bot <claude@openova.io>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
83f9fc429a