diff --git a/docs/backlog.md b/docs/backlog.md index 96d7010..3be3af2 100644 --- a/docs/backlog.md +++ b/docs/backlog.md @@ -34,7 +34,9 @@ historia incydentów, out-of-band watchdog. 5. ✅ ZROBIONE (2026-06-30, commit `62d6fc0`) — brain-watchdog: drugie wejście — poll Prometheus `/api/v1/alerts` (`firing`) → Telegram. Architektura A: dwa niezależne tory, mózg NIETKNIĘTY, debounce per-alert (klucz alertname:node w state.json). 12 testów pass. - PENDING: potwierdzenie end-to-end przy pierwszym realnym firing. + PENDING zamknięty 2026-07-02: poll POTWIERDZONY reconem (obraz zbudowany po `62d6fc0`, + `PROMETHEUS_URL` w `.env` i w env kontenera, zero poll failed) — patrz + `docs/infra/inventory-verify-2026-07-02.md`. 6. Rotacja tokenu HAOS w domowym prom (plaintext). 7. Przepięcie observer / panel `agents.okit.pl` na Prometheus jako źródło — największy znak zapytania przy cutoverze. @@ -44,19 +46,6 @@ historia incydentów, out-of-band watchdog. ## Aktywne -### brain-watchdog: brak logu PROMETHEUS_URL przy starcie - -**Data**: 2026-06-30 -**Źródło**: sesja 2026-06-30 (`docs/sessions/2026-06-30-prometheus-liveness.md`) -**Problem**: log startowy brain-watchdoga nie wypisuje `PROMETHEUS_URL` — utrudnia -potwierdzenie, że polling jest aktywny. Diagnoza "działa" opiera się na braku błędów -i zawartości `.env`, nie na logach. Pierwszy realny firing to jedyne pełne end-to-end -potwierdzenie. -**Fix**: dorzucić przy starcie jedną linię logu: `PROMETHEUS_URL set, polling enabled` -lub analogicznego `disabled` — tak jak robione dla `HEALTHCHECKS_URL`. - ---- - ### Gotchas (z 2026-06-30 — migracja kapala.org → Cloudflare/wildcard) **Data**: 2026-06-30 @@ -156,21 +145,6 @@ czy jest osiągalny po Tailscale z VPS, i czy ma sens go scrape'ować mimo LTE --- -### Ghost kontenery w panelu (Problem B — pozostałość po project-name divergence) - -**Data**: 2026-06-24 (wykryte), pozostaje otwarte po fixie Problemu A (2026-06-26) -**Źródło**: sesja 2026-06-24 + 2026-06-25 + 2026-06-26 -**Problem**: martwe kontenery ze starych project-name'ów -(`8547b46c0317_control-plane-supervisor`, `12bd3059a70f_control-plane-observer` itp.) -są raportowane przez observera jako `error` → `System Status ERROR` w panelu mimo -zdrowego realnego mózgu. -**Status**: destrukcyjny deploy (Problem A) NAPRAWIONY (`3b71707`, patrz Zamknięte), ale -ghosty z poprzednich rozjazdów wciąż wiszą. -**Fix**: `docker rm` ghostów na VPS; rozważyć czyszczenie kontenerów z obcym -project-name przy deployu. - ---- - ### Supervisor nie enqueue'uje akcji remediacji przy `error`-state **Data**: 2026-06-25 (powtórka sygnału z 2026-06-19) @@ -182,6 +156,9 @@ Podejrzane: supervisor może nie reagować na error-state jeśli źródłem są (błędne project-name), nie realne health-check failures. **Fix**: zbadać osobno — sprawdzić, czy supervisor otrzymuje właściwe eventy od observera, czy ma własną logikę de-duplifikacji blokującą enqueue. +**Update 2026-07-02**: ghost kontenery (bug B) zniknęły z VPS — jeśli objaw wróci, +hipoteza "źródłem są ghosty" jest już nieaktualna. UWAGA: ślepy supervisor na SATURN +(brak mountu repo, patrz sesja 2026-07-02) to INNY przypadek — nie mylić z tym bugiem. --- @@ -304,6 +281,46 @@ Długoterminowo: `agent.sh new` powinien odmawiać jeśli żądana gałąź jest ## Zamknięte +### Ghost kontenery w panelu (Problem B) — ZNIKNĘŁY (potwierdzone reconem 2026-07-02) + +**Data**: 2026-06-24 (wykryte), 2026-07-02 (zamknięte) +**Źródło**: sesje 2026-06-24/25/26; recon `docs/infra/inventory-verify-2026-07-02.md` +**Było**: martwe kontenery ze starych project-name'ów +(`8547b46c0317_control-plane-supervisor` itp.) raportowane przez observera jako +`error` → `System Status ERROR` w panelu mimo zdrowego mózgu. +**Zamknięte**: recon 2026-07-02 — 24 kontenery na VPS, ZERO hash-prefixed. +Prawdopodobnie recreate'y z kolejnych deployów je zmiotły. Zero akcji ręcznej. +Rozważenie czyszczenia obcych project-name przy deployu — już nieaktualne +(fix A `3b71707` blokuje źródło divergence). + +--- + +### brain-watchdog: poll Prometheus — POTWIERDZONY (recon 2026-07-02) + +**Data**: 2026-06-30 (pending), 2026-07-02 (zamknięte) +**Źródło**: recon `docs/infra/inventory-verify-2026-07-02.md` +**Było**: log startowy nie wypisuje `PROMETHEUS_URL` → brak pewności, że polling +aktywny; diagnoza opierała się na `.env` i braku błędów. +**Zamknięte**: recon potwierdził — obraz zbudowany po `62d6fc0`, `PROMETHEUS_URL` +w `.env` I w env kontenera, zero `poll failed` w logach. Poll aktywny. +Jednolinijkowy log startowy (`polling enabled/disabled`) pozostaje opcjonalną +kosmetyką; pełne end-to-end (firing → Telegram) potwierdzi pierwsza realna awaria. + +--- + +### Miny #1/#2/#3 z weryfikacji inwentaryzacji — ROZBROJONE (2026-07-02) + +**Źródło**: `docs/infra/inventory-verify-2026-07-02.md`, sesja +`docs/sessions/2026-07-02.md` (tam szczegóły i lekcje). +- **#1 PIHA checkout**: gałąź wciąż `task/kb-gmail-import` po resecie z 2026-06-30 + (reset --hard przesuwa gałąź, nie przełącza) → `checkout master && pull`, + 30 commitów nadrobione. +- **#2 control-plane na SATURN**: supervisor ślepy (brak mountu repo) → + `docker compose down`, wolumeny zachowane. Jedyny mózg = VPS. +- **#3 owner_node**: forgejo→piha, mosquitto→vps (commit `886bc85`). + +--- + ### 🔴 KRYTYCZNY — `deploy.sh vps` niszczył control-plane — NAPRAWIONE (commit `3b71707`) **Data**: 2026-06-24 (wykryte), 2026-06-25 (incydent w produkcji), 2026-06-26 (naprawione) @@ -391,11 +408,16 @@ gromadzi historię. Anomaly detection = osobny świadomy projekt później (CC, --- ## Rozjazdy repo<->rzeczywistosc (z inwentaryzacji 2026-06-30) **Zrodlo**: `docs/infra/inventory-2026-06-30.md` (23 rozjazdy, pelna tabela tam). +**Weryfikacja 2026-07-02**: `docs/infra/inventory-verify-2026-07-02.md` — bilans: +20 wciaz aktualnych, 2 zmienione, 1 wyjasniony (storage SOLARIA = partycja Windows +dual-boot, NIE rozjazd — zdjety z listy). Ponizej te wymagajace akcji, pogrupowane wg ryzyka. Naprawa = osobny task/kilka. ### Grupa A — czyste docs, zero ryzyka -- **forgejo** `service.yaml owner_node`: saturn -> piha (biega na PIHA always-on) -- **mosquitto** `service.yaml owner_node`: piha -> vps (biega na VPS, nie na PIHA) +- ✅ ZROBIONE (2026-07-02, commit `886bc85`) — **forgejo** `service.yaml owner_node`: + saturn -> piha (biega na PIHA always-on) +- ✅ ZROBIONE (2026-07-02, commit `886bc85`) — **mosquitto** `service.yaml owner_node`: + piha -> vps (biega na VPS, nie na PIHA) - **capabilities SATURN**: RAM 8 -> 14GiB; dysk sd-card 64GB -> /dev/sda 159GB - **capabilities SOLARIA**: CPU 24 -> 32 nproc - **`hosts/saturn/services.yaml`** nie istnieje — 5 kontenerow bez deklaracji @@ -405,8 +427,10 @@ Ponizej te wymagajace akcji, pogrupowane wg ryzyka. Naprawa = osobny task/kilka. - **npm x2**: PIHA (LAN ingress :80/:443) + VPS (public). Repo zna jedna (owner=vps). Decyzja: zostawic oba (intentional, wildcard cert via NPM@PIHA) czy usunac PIHA? Jesli oba zamierzone -> dodac piha do service.yaml + hosts/piha. -- **control-plane na SATURN**: biega (control-plane-ui UNHEALTHY) obok VPS. Repo zna tylko VPS. - Decyzja: dev-instance czy pomylka? Usuniecie odzyska zasoby + zlikwiduje UNHEALTHY. +- ✅ ZROBIONE (2026-07-02) — **control-plane na SATURN**: `docker compose down` + (wolumeny zachowane). Supervisor byl SLEPY (brak mountu repo, WARNING loop + "Hosts directory /repo/hosts does not exist" co 30s) — zero ryzyka zdublowanych + remediacji przez te 3 dni. Jedyny control-plane = produkcyjny na VPS. - **ollama**: `service.yaml owner=solaria` ale NIE biega. Wdrozyc czy wyrzucic z repo? ### Grupa C — sprzatanie @@ -415,13 +439,33 @@ Ponizej te wymagajace akcji, pogrupowane wg ryzyka. Naprawa = osobny task/kilka. albo curl w Dockerfile. (Przyczyna rozjazdu #6 znaleziona przy gaszeniu dysku.) - **homeassistant5 na PIHA** (HA "ken" :8123) niedeklarowany -> dodac do hosts/piha + topology - **VPS**: outline-postgres-1 anonimowy image (4e6e670bb069) -> named tag; - joplin-db postgres:18 (pre-release) -> postgres:17/16; humanai-landing/mailer/umami do repo + humanai-landing/mailer/umami do repo. ~~joplin-db postgres:18 -> 17/16~~ + (ocena zdezaktualizowana 2026-07-02: PG18 GA od 09/2025, nie pre-release — bez akcji) - **PIHA: 33 shadow kontenery** poza GitOps (immich, vaultwarden, wikijs, actual, audiobookshelf, elasticsearch, grafana, prom, portainer, code-server, diskover...) -> audyt + stopniowo do hosts/piha/services.yaml - **zigbee2mqtt** topology mowi chelsty-infra, biega na PIHA -> poprawic topology - **stability-agent / node_exporter** owner_node single, biegaja wielomiejscowo -> per-host +### Followupy z weryfikacji + rozbrajania min (2026-07-02) +**Zrodlo**: `docs/infra/inventory-verify-2026-07-02.md` + sesja 2026-07-02. +Zgloszone przy fixie owner_node (`886bc85`), swiadomie NIE ruszone — osobne decyzje. + +- **forgejo** brak wpisu w `hosts/piha/services.yaml`; **mosquitto** brak + w `hosts/vps/services.yaml` — schemat hostowy wymaga role/exposure/depends_on + (miny #2/#3/#16 z audytu). +- **mosquitto na VPS bez mem_limit override** w `hosts/vps/runtime/` — + narusza konwencje CLAUDE.md (kazdy serwis VPS deklaruje mem_limit). +- **drugi mosquitto na chelsty-infra** (offline'owa instancja) — pojedyncze + `owner_node` jej nie opisuje; wzorzec per-host jak stability-agent / + node_exporter (miny #17/#18). +- **topology.yaml:75**: mosquitto zadeklarowany tez jako komponent ai-cluster — + rozstrzygnac, czyj jest broker :1883. +- **pi-watchtower-1 na LUSTRO w restart-loopie** (nowe z reconu; node-agent healthy). +- **alias `lustro` nie rezolwuje z SOLARII** (nowe z reconu). +- **fleet-prometheus bez formalnego override mem_limit** w `hosts/vps/runtime/` — + limit siedzi w bazowym compose (kosmetyka). + ### Po odchudzaniu PIHA (2026-07-02, faza 2 modulu 0) - **llm-gateway: zlokalizowac/zarchiwizowac zrodlo** — kod (wlasny FastAPI router -> Ollama@SOLARIA) moze zyc TYLKO w `/opt/llm-gateway` na PIHA, bez gita; przeszukanie