jakman85andClaude Opus 5.5
24db269ea8
The Keycloak CR has no spec.image, so the operator's RELATED_IMAGE_KEYCLOAK picks the server image; the three keycloak-k8s-resources release URLs in platform/keycloak/kustomization.yaml are therefore THE Keycloak version, and Renovate could not see them (no `# renovate:` marker). They now carry markers under one depName (one branch, groupName keycloak-operator), with a packageRule: automerge false, labels needs-review + blast-radius; majors still wait on the dashboard. The untagged quay.io/keycloak/keycloak in catalog/keycloak.yaml renders apps/wave-1/keycloak.yaml, which no kustomization lists. It is pinned to the operator's 26.0.6 as documentation, re-rendered, and Renovate is disabled for that image so it cannot raise PRs against a file nothing deploys. The render is kept (not deleted): it is the fixture for apps/wave-1/tests/app-slis.test.yaml's keycloak SLI rule tests. README: an "Upgrading Keycloak" section — an operator bump must be checked against passkey-reconciler.yaml's 26.0.6 Admin API assumptions. Co-Authored-By: Claude Opus 5.5 <[email protected]>
apps
App-tier manifests, rendered from catalog/*.yaml ServiceDefinitions by catalog/render.py
and split into dependency-ordered waves (wave-<N>/).
- Each
wave-<N>/is reconciled by its own Flux Kustomizationapps-wave-<N>(clusters/base/apps-wave-<N>.yaml), whichdependsOnwave N-1 (wave 0 dependsOnplatform-config) and health-gates (wait: true) ONLY that wave. A crashlooping workload in a later wave can no longer stall an earlier wave or block new revisions. wave-<N>/kustomization.yamlandclusters/base/apps-wave-<N>.yamlare generated — runpython3 catalog/render.py --emit-wavesafter onboarding a service; do not hand-edit them.- Wave assignment = longest dependency-path depth over the catalog
dependencies:graph; a co-located CNPG database<svc>-dbis a leaf and always lands strictly below its consumer.
See ../DESIGN-waves.md for the wave table, Flux topology, and the
cutover runbook.