From b393687d1058e2b632737519292055c99322fc7c Mon Sep 17 00:00:00 2001 From: Sergio Date: Wed, 9 Sep 2026 20:21:53 +0000 Subject: [PATCH] ADR 0016: worker migrado, y corregida una recaida del barrido El worker vive en /opt/takana con takana-farm.service, verificado por un ciclo de build real alla y una cosecha completa aca. Y queda anotada la recaida: el barrido ad-hoc de este mismo cambio no respeto el aviso que este fichero tiene arriba y dio vuelta cuatro afirmaciones HISTORICAS, dejandolo diciendo que a las 18:40 se reinicio takana-farm.service cuando en ese momento se llamaba hammer-farm.service. Corregidas a mano. La exclusion hay que ponerla en CADA barrido, no una sola vez. --- docs/adr/0016-renombre-takana.md | 32 +++++++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git a/docs/adr/0016-renombre-takana.md b/docs/adr/0016-renombre-takana.md index 2133bd1f..99596a80 100644 --- a/docs/adr/0016-renombre-takana.md +++ b/docs/adr/0016-renombre-takana.md @@ -93,7 +93,7 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con - ADRs y docs de diseño: texto, y `hammer` sigue funcionando. Van con la etapa 5. **Cómo converge el worker** (medido el 2026-09-09, no supuesto). Su checkout vive en - `/opt/hammer`, **no es un clon git** —lo pone el rsync de la siembra— y `takana-farm.service` + `/opt/hammer`, **no es un clon git** —lo pone el rsync de la siembra— y `hammer-farm.service` está `enabled` allá, corriendo `farm-worker-loop.sh` como servicio largo. En el momento del cambio el worker tenía scripts viejos y binario del 6-sep: **coherente**. Los dos estados intermedios también lo son, y por eso la 3a iba primero: @@ -105,7 +105,7 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con La unit apunta a la RUTA DEL SCRIPT, no al binario, así que nada de la etapa 3 la toca. El nombre del fichero de unit y `/opt/hammer` son etapa 6. - **Convergido y comprobado (2026-09-09 18:40–18:45Z).** Reiniciado `takana-farm.service`, el + **Convergido y comprobado (2026-09-09 18:40–18:45Z).** Reiniciado `hammer-farm.service`, el worker compiló los dos binarios y **cerró un ciclo de build real con el nombre nuevo**: `✓ dunst b3:29a79859…`, BUILD-YIELD 1/1, 1 promovido. No es que «no se rompió nada visible»: el camino de construir y sellar se ejercitó entero. @@ -197,7 +197,7 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con reescribir historia es peor que un mensaje incompleto. El detalle vive acá.)* **Congelados y verificados con controles:** `/opt/hammer`, `/var/lib/hammer`, `/usr/bin/hammer`, - `/mnt/vvv/hammer`, la URL de gitea, `takana-farm.service`, `hammer-live-install.sh`, + `/mnt/vvv/hammer`, la URL de gitea, `hammer-farm.service`, `hammer-live-install.sh`, `BRIEFING-hammer.md`, `hammerd`, `hammer-recover`, `HAMMER_LIVE`, `.hammer-zig-cc`, `.hammer-cargo-vendor` y dos identificadores más que aparecieron al barrer: - `hammer-build-state/1` — el `schema` del estado generado. Nadie lo valida, pero el valor de un @@ -236,8 +236,30 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con - 🔒 **`/usr/bin/hammer` dentro del rootfs del producto** — está **dentro de un árbol que se hashea**. Moverlo cambia el hash del producto y obliga a rehacer el baseline del selfhost. Va junto con esa deuda, no antes. - - ⚠ **`takana-farm.service` y `/opt/hammer`** — despliegue coordinado en el worker: parar, - renombrar, `daemon-reload`, arrancar. Reversible, pero es hacia afuera. + - ✅ **`/opt/takana` y `takana-farm.service`** (2026-09-09 ~20:15Z). Sin montajes adentro esta + vez, así que el `mv` fue directo. + + **El orden no era cosmético:** el hub siembra por `rsync` a una ruta fija, así que el cron se + sacó ANTES de mover. Al revés, la siguiente cosecha habría recreado `/opt/hammer` y el worker + quedaba **partido en dos árboles** sin que nada fallara. + + Un detalle que el primer `sed` no casó: `systemctl restart hammer-farm` y + `journalctl -u hammer-farm` nombran la unit **sin el sufijo `.service`**. + + **Verificado:** el worker cerró un ciclo de build real desde `/opt/takana` (`dunst` sellado, + 1/1) y una cosecha completa del hub contra la ruta nueva pasó siembra, manifiesto, los nueve + grafos, `static-audit` (691 estáticos, MIENTEN 0) y estado pusheado. + + **Dos referencias a `/opt/hammer` quedan a propósito porque siguen siendo ciertas:** + `docs/23-plan-rehasheo.md` describe rutas **embebidas en artefactos ya construidos** —sus + secciones `.debug` literalmente dicen `/opt/hammer/work`— y el HANDOFF de la noche de KDE es + registro. Cambiarlas haría que los documentos mientan sobre lo que hay en el disco. + + ⚠ **Y una recaída, anotada porque es la misma trampa dos veces:** el barrido ad-hoc de este + mismo cambio (`git grep -l … | sed`) NO respetó el aviso de arriba y dio vuelta cuatro + afirmaciones **históricas** de este fichero, dejándolo diciendo que a las 18:40 se reinició + `takana-farm.service` cuando en ese momento se llamaba `hammer-farm.service`. Corregidas a + mano. La exclusión hay que ponerla en **cada** barrido, no una vez. - ✅ **`/mnt/vvv/hammer` → `/mnt/vvv/takana`, y el repo renombrado en gitea a `sergio/takana`** (2026-09-09 ~20:00Z). Se coordinó primero: se avisó a las dos sesiones `hammer-*` y `hammer-9f` contestó «vía libre», con los locks comprobados libres y sin builds en vuelo.