autonomic-bot
61211dba70
canonical_domain() routes any recipe in warm.WARM_DOMAINS (keycloak) to a distinct warm-canon-<recipe> domain so the data-warm canonical promote can never collide with the live-warm OIDC provider at warm-keycloak. keycloak WARM_CANONICAL=True (full canonical coverage without risking live SSO).
19 lines
1.2 KiB
Python
19 lines
1.2 KiB
Python
# Per-recipe harness config for keycloak (DB-backed: keycloak + mariadb). Read by the shared
|
|
# conftest — enrolling this recipe needs NO change to runner/harness code (D5).
|
|
HEALTH_PATH = "/realms/master" # 200 JSON once keycloak is up (not "/", which redirects)
|
|
HEALTH_OK = (200,)
|
|
DEPLOY_TIMEOUT = (
|
|
900 # JVM + DB migration are slow on a 2-vCPU VM; observed 502 fallback up to ~10min
|
|
)
|
|
HTTP_TIMEOUT = 900
|
|
|
|
# phase redfix: keycloak IS now a data-warm canonical. The original canon §2.B exception de-enrolled
|
|
# it because its canonical would have used the SAME domain as the live-warm OIDC provider
|
|
# (warm-keycloak.ci.commoninternet.net), so the sweep's promote deploy/teardown would collide with the
|
|
# live service lasuite-*/drone depend on. That collision is now structurally impossible:
|
|
# `canonical.canonical_domain()` routes any recipe in `warm.WARM_DOMAINS` (keycloak) to a distinct
|
|
# `warm-canon-<recipe>` domain/stack, so the data-warm canonical and the live-warm provider are
|
|
# separate deployments that can never touch each other. keycloak therefore gets full data-warm
|
|
# canonical coverage (a real promote on its latest release) without risking the live OIDC service.
|
|
WARM_CANONICAL = True
|