1bab3219d6
Warunek zdjecia M1 brzmial "R1 (prune filtrowany po restart policy / labelu
compose) wdrozony na tym nodzie". Zweryfikowane bezposrednio w kodzie dzialajacych
kontenerow, nie po datach deployu:
SOLARIA md5(/app/src/node_agent.py) = c9ac64e10b42b3e0ed9e4c168579bfaa,
identyczny z origin/master.
VPS rozni sie od origin/master wylacznie trescia komentarzy (5 linii
`docs/backlog.md` vs `kb/phases/backlog.md`, skutek migracji sciezek
w 9128530) — zero roznic funkcjonalnych.
Na obu nodach `_prune_stopped_containers` jest obecny (te same numery linii:
635/700/717/725), a jedyne wystapienia `containers.prune()` to tekst docstringa
i komentarza — brak wykonywalnego niefiltrowanego prune. Sprawdzone dodatkowo,
ze scripts/monitor/health-monitor.sh (ktory nadal ma niefiltrowane
`docker container prune -f` — R1 objelo tylko node_agent.py) nie jest wpiety w
zaden crontab ani timer na SOLARII i VPS, wiec node-agent byl faktycznie jedynym
zrodlem prune i cleanup byl na obu nodach realnie wylaczony.
SOLARIA: przywrocone jawne NODE_TYPE=ai_node — stan sprzed M1 (1cd6401),
zgodnie z konwencja pozostalych hostow, ktore wszystkie ustawiaja NODE_TYPE
jawnie (piha/lustro sd_card, chelsty-infra lte_node). solaria jest w AI_NODES,
wiec default dalby to samo, ale jawny wpis nie zalezy od hostname'u.
VPS: linia usunieta w calosci wraz z komentarzem TEMPORARY — dokladny stan
sprzed 11f3f80, gdzie NODE_TYPE nie bylo ustawione wcale. Potwierdzone, ze
default daje `standard`, nie None: base compose przekazuje `NODE_TYPE=${NODE_TYPE:-}`,
czyli pusty string, ktory jest falsy, wiec _resolve_node_type() schodzi do
rozpoznania po nazwie, a `vps` nie nalezy do LTE_NODES/SD_CARD_NODES/AI_NODES.
Sprawdzone na zlozonym `docker compose config` (NODE_TYPE: "") i uruchomieniem
_resolve_node_type() -> 'standard'. Rotacja filesystemu control-plane jest
bramkowana node_name == VPS_NODE_NAME, nie node_type, wiec dziala niezaleznie.
UWAGA DO DEPLOYU: na obu nodach brak /opt/homelab/state/last-docker-cleanup,
a przy braku markera _cleanup_rate_ok() zwraca True — pierwszy cleanup pojdzie
w pierwszym cyklu po restarcie (<=60 s), nie po 24 h jak na LUSTRO.
W chwili sprawdzenia zero kontenerow `exited` na obu nodach, wiec galaz
kontenerowa nie ma czego usunac; do sprzatniecia sa 4 dangling images na SOLARII
(~553 MB) i 1 na VPS (395 MB) plus build cache. humanai-mailer i humanai-landing
maja restart=unless-stopped, wiec sa chronione pierwsza galezia filtra R1 nawet
gdyby zostaly zatrzymane.
node-agent: 70 passed.
Refs docs/incidents/2026-07-30-ollama-solaria-vanish.md (§7, M1),
docs/sessions/2026-08-06.md (follow-up #5)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
24 lines
1.1 KiB
YAML
24 lines
1.1 KiB
YAML
services:
|
|
node-agent:
|
|
# Docker GID on SOLARIA is 996 (not the Debian default 999 the base compose
|
|
# assumes). Without this the agent starts with "Docker unavailable:
|
|
# Permission denied" on /var/run/docker.sock and reports no containers
|
|
# (recon RECON-multiagent-2026-07-27.md, A2/E19). Compose concatenates
|
|
# group_add lists, so the base 999 stays alongside; 996 is what grants
|
|
# socket access here. Same per-host pattern as piha (123) and lustro (991).
|
|
group_add:
|
|
- "996" # host docker gid, verified 2026-07-30 (getent group docker → 996)
|
|
environment:
|
|
- NODE_NAME=solaria
|
|
# ai_node = dangling images + kontenery + build cache, ale NIGDY
|
|
# `image prune -a` (skasowałoby obrazy runtime Ollamy). Ustawione jawnie,
|
|
# zgodnie z konwencją pozostałych hostów, mimo że solaria jest w AI_NODES
|
|
# w node_agent.py i default dałby to samo.
|
|
- NODE_TYPE=ai_node
|
|
- VPS_EVENTS_HOST=100.95.58.48
|
|
- VPS_EVENTS_USER=oskar
|
|
- VPS_EVENTS_PATH=/opt/homelab/events
|
|
- CHECK_INTERVAL=60
|
|
volumes:
|
|
- /home/oskar/.ssh:/home/homelab/.ssh:ro
|