fix(keycloak): one owner for the keycloak ServiceMonitor (26.8 operator 409 loop blocks Flux)
The 26.x Keycloak operator creates its own ServiceMonitor named after the CR (keycloak/keycloak) when metrics are enabled; spec.serviceMonitor.enabled defaults true. That collides with the Flux-owned platform/keycloak/ servicemonitor.yaml: the operator's PATCH 409s, it exhausts retries, the CR stays Ready=False/HasErrors=True, and platform-config (wait: true) stalls every downstream Kustomization. Keep the repo's ServiceMonitor (conformance L0/L2 and the dashboard are written against it; the operator's scrapes the same port 9000 /metrics) and set spec.serviceMonitor.enabled: false. Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
1 parent
1a33814522
commit
35ba875380
3 files changed
+77
No files matched your search
@@ -38,6 +38,20 @@ spec:
|
||||
ingress:
|
||||
enabled: false # exposed via Gateway API HTTPRoute (httproute.yaml), not the
|
||||
# operator's built-in Ingress
|
||||
# --- ONE OWNER for the `keycloak` ServiceMonitor: this repo (servicemonitor.yaml), not the operator.
|
||||
# Since 26.x the operator creates its OWN ServiceMonitor, named after this CR (`keycloak`, i.e.
|
||||
# the SAME name/namespace as ours), whenever metrics-enabled=true and the CRD exists —
|
||||
# spec.serviceMonitor.enabled defaults TRUE. On 2026-11-08, right after the 26.0.6 -> 26.8.2
|
||||
# bump, its server-side apply onto our Flux-owned object failed `409 Conflict`, the operator
|
||||
# exhausted retries, the CR sat Ready=False/HasErrors=True, and `platform-config` (wait: true,
|
||||
# so it health-checks this CR) stalled every Kustomization downstream of it. Ours is kept
|
||||
# because the L0 servicemonitor-ports-resolve and L2 keycloak-monitored conformance tests and
|
||||
# the dashboard's up{namespace="keycloak"} are written against it; the operator's would scrape
|
||||
# the same thing (management port 9000, /metrics, 30s). Do NOT flip this to true without
|
||||
# deleting servicemonitor.yaml in the same change — two owners of one object is a fight
|
||||
# (cf. the default-deny NetworkPolicy drift loop).
|
||||
serviceMonitor:
|
||||
enabled: false
|
||||
# --- Hardening + observability options (docs/15). Brute-force detection is a REALM setting
|
||||
# (bruteForceProtected in the realm import); these enable health + metrics endpoints. ---
|
||||
additionalOptions:
|
||||
|
||||
Reference in new issue
Block a user