gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1488Shell 182Rust 107Markdown 963619 Definitions

⎇ 7f2ebdbb8b27ff40d6f670f8e7767f58b1bbc2bf docs/runbooks/harkaq-granja-volumen.md Markdown · 42 lines · 2.1 KB History raw

harkaq: granja con volumen + auto-shutdown VALIDADA end-to-end 35f58aa75 · sergio ·

1# Granja harkaq con volumen persistente + auto-shutdown
2
3La arquitectura que la 1ª campaña pidió (quedó idle ~4h cobrando). El worker no depende de que yo
4esté viva y no se queda idle. **Validado end-to-end 2026-07-16** (worker se auto-eliminó, volumen
5sobrevivió con las cosechas, helper efímero las recogió).
6
7## Ciclo
8
9```sh
10scripts/farm/harkaq-vol.sh up 2      # 2 workers midiendo → volumen; se auto-eliminan al agotar cola
11# ... (muelen la noche, se destruyen solos) ...
12scripts/farm/harkaq-vol.sh collect   # (cuando esté viva) helper efímero baja las cosechas al hub
13scripts/farm/harkaq-vol.sh close     # clausura el volumen (deja de cobrar)
14scripts/farm/harkaq-vol.sh status
15```
16
17## Cómo funciona (y por qué así)
18
19- **Volumen `harkaq-cosecha`**: los workers escriben verdicts a `/mnt/cosecha`, que **sobrevive a
20  su destrucción**. No dependo de estar viva para no perder el trabajo.
21- **Auto-shutdown**: tras `IDLE_CICLOS` ciclos con 0 mediciones nuevas, el worker **se auto-elimina
22  vía API REST** (`curl` + metadata service; NO hcloud CLI, que la golden no trae). En Hetzner un
23  server apagado **sigue cobrando** ⇒ apagar de verdad es `delete`.
24- **collect**: monta el volumen en un helper efímero barato (o un worker vivo), rsync al hub, lo
25  destruye. Clasificar los verdicts es un paso aparte (el worker MIDE, el hub CLASIFICA con el
26  store completo).
27
28## Rastrillos que ya se pagaron (todos verificados en vivo)
29
30- **`--exclude /work` es crítico**: `work/` son 69GB; sin excluirlo el rsync del `up` cuelga horas.
31- **Tipo de server**: en hel1 los AMD `cpx*` dan "unsupported/stock"; `ccx13`/`ccx23` sí van.
32- **El token va al worker** (para auto-delete): riesgo acotado — efímero, sin servicios entrantes.
33- **`${1:?...}` sin llaves** en el mensaje: una `}` interna cierra la expansión.
34- El bucle **borra el artefacto `-hkm` tras medir** (envenenaba la caché en la 1ª campaña) y gatea
35  por ABI≥7 + binario-con-jaula (no medir ciego).
36
37## Parar de emergencia
38```sh
39hcloud server list | grep hkw       # ver workers
40hcloud server delete hkw-N          # matar uno
41scripts/farm/harkaq-vol.sh close    # y el volumen
42```

harkaq-granja-volumen.md

Granja harkaq con volumen persistente + auto-shutdown

La arquitectura que la 1ª campaña pidió (quedó idle ~4h cobrando). El worker no depende de que yo esté viva y no se queda idle. Validado end-to-end 2026-07-16 (worker se auto-eliminó, volumen sobrevivió con las cosechas, helper efímero las recogió).

Ciclo

scripts/farm/harkaq-vol.sh up 2      # 2 workers midiendo → volumen; se auto-eliminan al agotar cola
# ... (muelen la noche, se destruyen solos) ...
scripts/farm/harkaq-vol.sh collect   # (cuando esté viva) helper efímero baja las cosechas al hub
scripts/farm/harkaq-vol.sh close     # clausura el volumen (deja de cobrar)
scripts/farm/harkaq-vol.sh status

Cómo funciona (y por qué así)

Rastrillos que ya se pagaron (todos verificados en vivo)

Parar de emergencia

hcloud server list | grep hkw       # ver workers
hcloud server delete hkw-N          # matar uno
scripts/farm/harkaq-vol.sh close    # y el volumen