From 6a5c5f3e13ab18419d35e16a88f0b5e45dd4e09e Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Sat, 30 May 2026 14:07:50 +0100 Subject: [PATCH] =?UTF-8?q?review(2):=20discourse=20Q4.6=20=C2=A77.1=20pre?= =?UTF-8?q?-positioning=20=E2=80=94=20premise=20VERIFIED=20first-hand=20(a?= =?UTF-8?q?ll=20bitnami/discourse:{3.1.2,3.3.1,3.4.5}=3D404,=20bitnamilega?= =?UTF-8?q?cy=3D200,=20upstream=20newest=200.8.0+3.4.5);=20deferral=20NOT?= =?UTF-8?q?=20yet=20established=20(honest=20uniform-overlay=20crossover=20?= =?UTF-8?q?may=20make=20upgrade=20tier=20testable=20iff=20prev=20base=3D?= =?UTF-8?q?=3Dhead=20image=20ver);=20decisive=20fact=20OPEN;=20bar=20set;?= =?UTF-8?q?=20not=20a=20verdict?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- machine-docs/REVIEW-2.md | 57 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/machine-docs/REVIEW-2.md b/machine-docs/REVIEW-2.md index 904a3d9..ec1f8d4 100644 --- a/machine-docs/REVIEW-2.md +++ b/machine-docs/REVIEW-2.md @@ -2016,3 +2016,60 @@ window. So the forward-looking **Q5/DONE criterion still holds**: before I sign "a full green `!testme` run" + D7 results-UX), OR (b) an operator-blessed STATUS-2 statement that host `cc-ci-run` validation satisfies P1 (trigger recipe-agnostic, proven once in D10) and an empty live dashboard is acceptable for DONE. NOT a veto; not blocking in-progress work. + +## Break-it probe @2026-05-30T13:07:50Z — discourse Q4.6 §7.1 (upgrade-tier deferral) PRE-POSITIONING — premise VERIFIED; deferral NOT yet established (NOT a verdict; gate unclaimed) +discourse Q4.6 is NOT formally claimed and no §7.1 sign-off is owed yet (Builder flagged the intent in +STATUS-2 880ba78, not via my inbox). This is disbelieve-first pre-positioning so the bar is set before any claim. + +**VERIFIED FIRST-HAND (cc-ci host, Docker Hub registry v2 API; sanity debian:latest=200, token auth OK):** +- `bitnami/discourse:3.1.2` → **404**, `:3.3.1` → **404**, `:3.4.5` → **404** (ALL removed). +- `bitnamilegacy/discourse:3.1.2` → **200**, `:3.3.1` → **200**, `:3.4.5` → **200** (ALL served). +- Upstream (`abra recipe fetch discourse`) newest published tag = **`0.8.0+3.4.5`** (newer than the + `0.7.0+3.3.1` the Builder's re-pin PR targets). Its compose also pins bitnami/discourse (→404). +⇒ The Builder's **factual** premise is TRUE: every published discourse version pins a now-removed + `bitnami/discourse:*` image; the drop-in `bitnamilegacy/discourse:*` is served for every tag. + +**HARNESS MECHANISM (read first-hand: run_recipe_ci.py:725-729, lifecycle.py:200-263, 508-510):** +- Upgrade tier base-deploys `base = previous_version(recipe) = recipe_versions()[-2]` (2nd-newest + PUBLISHED tag), via `deploy_app(version=prev)` → `abra recipe checkout ` → deploy that + tag's compose. That compose pins `bitnami/discourse:` (404) → base deploy fails. **The + cc-ci overlay (compose.ccci-health.yml) only raises healthcheck start_period; it does NOT re-pin the + image.** The HEAD re-pin lives in the PR-head compose, not the overlay. +- COMPOSE_FILE/EXTRA_ENV overlay is "applied at EVERY deploy (install + upgrade's old_app)" + (lifecycle.py:77) — i.e. **version-UNIFORM**: one static overlay hits both the prev base deploy and + the chaos head redeploy identically. + +**DISBELIEVE-THE-"UNTESTABLE" ANALYSIS (the §7.1 crux — CONDITIONAL, one fact still to verify):** +§7.1 says "needs effort / needs a workaround" is NOT a valid deferral; only a true environment-level +blocker is. So the real question isn't "is the published image gone" (yes) but "can an HONEST upgrade +crossover still be built." A static image-override overlay (`services.app.image: bitnamilegacy/discourse:`) +is version-uniform, so it pins the SAME image on BOTH base and head. Therefore: + • IF the harness's chosen prev base and the PR head target the **same** discourse image version + (Builder's PR is a pure namespace re-pin at 3.3.1: 0.7.0+3.3.1 → 0.8.0+3.3.1), then a uniform + `image: bitnamilegacy/discourse:3.3.1` overlay is CORRECT for both deploys → an **honest** crossover + (version-label/commit 0.7.0→head while running the identical, servable 3.3.1 image) → the upgrade + tier **IS testable with modest overlay effort** ⇒ deferral **NOT warranted**. + • IF the chosen prev base is a DIFFERENT discourse version than head (e.g. previous_version picks + 0.6.3+**3.1.2** while head is **3.3.1**), a uniform overlay would force head onto 3.1.2 → a HOLLOW + "upgrade" (running the old image under the head version label) which §7.1 forbids; an honest + crossover would then require a version-AWARE overlay = a harness change (infra, out of Phase-2 + scope) ⇒ deferral **more defensible**. + +**DECISIVE OPEN FACT (not yet verified first-hand — host output truncated):** which version does +`recipe_versions(discourse)[-2]` resolve to **for this run** (mirror SRC=recipe-maintainers/discourse + +REF=head), and does it share discourse's image version (3.3.1) with the PR head? That single fact +decides sound-vs-unwarranted. I will resolve it before ruling. + +**Pre-positioned §7.1 bar (must ALL hold before I'd sign off the upgrade-tier deferral):** +1. Builder demonstrates the prev base and PR head are **different** discourse image versions (so a + uniform overlay can't honestly bridge them), OR implements the honest uniform-overlay crossover and + runs the upgrade tier green. "All published images removed" alone is NOT sufficient — bitnamilegacy + is served, so servability is not the blocker; honest-crossover-impossibility is the bar. +2. Maximal subset (install,backup,restore,custom on PR head) genuinely GREEN, deploy-count=1, + clean teardown. +3. P4 backup/restore **non-vacuous** (seeded marker survives; negative control RED), ≥2 real P3 + functional tests (create-topic round-trip etc., not health-only). +NOT a veto, NOT a verdict — recorded so the §7.1 ruling is rigorous when the gate is claimed. + +(Harness caveat: tool-output garbled/duplicated lines this session; every VERIFIED fact above was +re-confirmed and is consistent across duplicated outputs; the one truncated fact is explicitly marked OPEN.)