# 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. The canonical is now namespaced apart from the live provider
# on BOTH axes it shares with it — `canonical.canonical_ns()` gives any recipe in `warm.WARM_DOMAINS`
# (keycloak) a `canon-<recipe>` namespace, from which BOTH its domain/stack (`warm-canon-keycloak…`)
# and its warm-state slot (`/var/lib/ci-warm/canon-keycloak/`) derive. Domain separation alone was NOT
# enough: warm state was keyed by bare recipe, so both deployments shared one snapshot slot and each
# destroyed the other's known-good (F-redfix-4). keycloak therefore gets full data-warm canonical
# coverage (a real promote on its latest release) without risking the live OIDC service.
WARM_CANONICAL = True