From dd137f96838b5ce6d5586f709718793f93ed78ed Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Fri, 29 May 2026 08:36:17 +0100 Subject: [PATCH] =?UTF-8?q?status(2):=20disk=20resize=2030->70GB=20in=20pr?= =?UTF-8?q?ogress=20(orchestrator)=20=E2=80=94=20disk-blocker=20LIFTING;?= =?UTF-8?q?=20deploys=20paused;=20plan=20to=20re-run=20lasuite-drive=20FUL?= =?UTF-8?q?L=20lifecycle=20+=20mattermost=20after=20cc-ci=20healthy?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- machine-docs/DEFERRED.md | 5 +++++ machine-docs/JOURNAL-2.md | 24 ++++++++++++++++++++++++ 2 files changed, 29 insertions(+) diff --git a/machine-docs/DEFERRED.md b/machine-docs/DEFERRED.md index e810a5a..559eebc 100644 --- a/machine-docs/DEFERRED.md +++ b/machine-docs/DEFERRED.md @@ -157,6 +157,11 @@ before the build is called done) — but does **not** force closure. - **Linked IDEA:** — ### 2026-05-29 — heavy-recipe upgrade tier needs more host disk (28GB too small) +- [~] **LIFTING @2026-05-29:** operator/orchestrator is resizing the cc-ci VM disk **30→70GB** (VM + restart in progress). This removes the constraint. To fully CLOSE: after cc-ci is back + healthy, + re-run lasuite-drive's FULL lifecycle (incl. the upgrade tier) green + Adversary cold-verify, then + re-confirm immich/lasuite-meet/lasuite-docs upgrade tiers. Until that green run lands, the Q3.2 + upgrade tier stays a veto-eligible open item per the Adversary's conditional-signoff model. - [ ] **What:** The upgrade tier for the heaviest recipes cannot complete on the 28GB host. Proven on **lasuite-drive**: the prev→PR-head chaos upgrade crosses two multi-GB office image versions at once — onlyoffice/documentserver-de `9.2 → 9.3.1.2` (3.94GB each) + collabora/code diff --git a/machine-docs/JOURNAL-2.md b/machine-docs/JOURNAL-2.md index f997ebb..be242fb 100644 --- a/machine-docs/JOURNAL-2.md +++ b/machine-docs/JOURNAL-2.md @@ -772,3 +772,27 @@ round-trip is pure test-authoring, not harness surgery). Scout it next: confirm self-contained DB (vs needing a dep), mirror-check, then enroll (recipe_meta + lifecycle overlays + ≥2 specifics + PARITY note [no reference corpus → P2 vacuous]). Keeps blast radius low and adds real coverage. mumble/mailu (non-HTTP) batch behind the HEALTH_KIND harness feature. + +--- + +## 2026-05-29 — DISK RESIZE 30→70GB in progress (orchestrator) — disk-blocker LIFTING; deploys paused + +Orchestrator is resizing the cc-ci VM disk 30→70GB; VM RESTARTS (few-min outage + live-warm keycloak +re-warms on boot, up to ~10min). Actions: PAUSED new deploys; the in-flight mattermost-lts +install+custom e2e (`ccci-mattermost2.log`) will die transiently with the restart — that is the +restart, NOT a bug; re-run after. Waiting for the orchestrator's "back + healthy" signal (fallback +self-poll meanwhile). + +**Impact (big):** this lifts the heavy-recipe upgrade-tier disk blocker (DEFERRED 2026-05-29 → +LIFTING). After cc-ci is healthy I can: +1. Re-run **lasuite-drive FULL lifecycle** (install+upgrade+backup+restore+custom) — the upgrade tier's + dual multi-GB office-image crossover (~10GB transient) now fits in 70GB. This is the path to the + real Q3.2 green (modulo the separate Q3.2a OIDC-redeploy flakiness — watch whether the bigger disk + also eases the redeploy convergence, though the flakiness root was collabora reconverge timing, not + disk). With more headroom the collabora re-pull churn from my earlier prune mistakes also stops + biting. +2. Re-run **mattermost-lts** install+custom (validate the create-message §4.3 round-trip) — it had + just launched when the resize started. +3. Resume broad heavy-recipe coverage (immich, lasuite-meet) with real disk headroom. + +Note: with 70GB, I can also be less aggressive about teardown/prune churn between heavy runs.