From 9771b6e16a9bcab134683e883a4c4bd21b0e5526 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Sat, 30 May 2026 05:06:22 +0100 Subject: [PATCH] =?UTF-8?q?fix(2):=20ghost=20timeout=202400->900=20?= =?UTF-8?q?=E2=80=94=20VM=20now=204=20dedicated=20vCPU=20(operator),=20mig?= =?UTF-8?q?ration=20converges=20in=20minutes;=20short=20bounded=20budget?= =?UTF-8?q?=20fails=20fast=20on=20the=20migrations=5Flock=20deadlock=20ins?= =?UTF-8?q?tead=20of=20a=20long=20blackout?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- tests/ghost/recipe_meta.py | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/tests/ghost/recipe_meta.py b/tests/ghost/recipe_meta.py index dccdac5..d5a5861 100644 --- a/tests/ghost/recipe_meta.py +++ b/tests/ghost/recipe_meta.py @@ -8,15 +8,14 @@ # mysqldump pre-hook; P4 (ops.py + test_{backup,restore,upgrade}.py) seeds a `ci_marker` row there. HEALTH_PATH = "/" # Ghost serves a themed site HTML at root (200) HEALTH_OK = (200,) -DEPLOY_TIMEOUT = 2400 # subprocess timeout for `abra app deploy` +DEPLOY_TIMEOUT = 900 # subprocess timeout for `abra app deploy` HTTP_TIMEOUT = 900 # Ghost's first-boot does a full schema migration (dozens of tables) against a fresh MySQL `ghost` -# DB. On cc-ci's slow single node this takes ~6min, during which the recipe healthcheck -# (start_period 1m → ~5min grace) marks the still-booting task unhealthy and swarm kills it; the -# NEXT task finds the schema already created and boots fast → converges. But the first task's -# migration + the early MySQL-not-ready (`exit 2`) app restarts can eat ~18min, so the default 1200s -# convergence wait timed out right as it was converging. Bump to 2400s (matched to DEPLOY_TIMEOUT) so -# the post-migration fast-boot task has room to converge within one deploy (the volume persists -# across the in-deploy task restarts). Documented as heavy-recipe cold-boot fragility in DECISIONS. -EXTRA_ENV = {"TIMEOUT": "2400"} +# DB. The migration must finish within the recipe healthcheck grace (start_period 1m + 10×30s ≈ 6min) +# — otherwise swarm kills the still-migrating task, which leaves a stale `migrations_lock` row and +# every later task then refuses to boot (`MigrationsAreLockedError` deadlock). On the cc-ci node with +# 4 dedicated vCPU the migration completes well inside that grace and the app converges in a few +# minutes, so 900s is an ample-but-bounded budget (fails fast if the deadlock ever recurs, rather +# than a long blackout). See DECISIONS (ghost MySQL cold-boot). +EXTRA_ENV = {"TIMEOUT": "900"}