4658089e21
126 plikow (md, yaml, sh, py) odwolywalo sie do sciezek sprzed migracji.
15 markdown-linkow [..](..) -> policzona sciezka WZGLEDNA wobec pliku
odsylajacego (wczesniej czesc z nich byla repo-root-relative i nie
rozwiazywala sie z katalogu, w ktorym lezala)
200 odwolan tekstowych (backticki, proza, yaml, importy w kodzie)
-> nowa sciezka repo-root-relative, zgodnie z konwencja repo
5 linkow rodzenstwa (gole nazwy plikow, np. "](DEPLOY.md)") — dzialaly
tylko w starym katalogu; przeliczone recznie
Objete m.in.: CLAUDE.md (scripts/onboard/README.md -> kb/runbooks/
node-onboarding-tool.md, docs/backlog.md -> kb/phases/backlog.md),
README.md, .claude/skills/, 20 session logow, kod jobow.
Ostatnie 5 odwolan pochodzi z tresci wciagnietej rebasem z origin/master
(session log 2026-07-31, override node-agenta na SOLARII, dwie pozycje
backlogu) — wskazywaly na docs/incidents/, docs/kb/modules/ i
services/narty27/README.md sprzed migracji.
Dodany wzajemny link miedzy kb/services/control-plane.md (stub kodu)
a kb/subsystems/control-plane.md (opis, deprecated) — dwa dokumenty o tym
samym systemie, latwe do pomylenia.
Weryfikacja na 790 plikach: 0 odwolan do starych sciezek,
0 martwych linkow markdown. Lint OKF: 190/190 plikow ZGODNE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
70 lines
3.4 KiB
Markdown
70 lines
3.4 KiB
Markdown
---
|
|
okf: "0.1"
|
|
type: phase
|
|
visibility: private
|
|
status: active
|
|
updated: 2026-07-28
|
|
links: []
|
|
---
|
|
|
|
# Plan naprawy subsystemu A (control-plane) — 2026-07-28
|
|
|
|
Kontekst: kb/subsystems/recon-multiagent.md. Decyzje bazowe:
|
|
- Flota dzieli się na dwa subsystemy. A = utrzymaniowy (control-plane, node-agenty,
|
|
self-healing) — ten plan. B = zleceniowy (dyspozytor + Telegram + KB + HA +
|
|
homelab-ops) — prowadzony w osobnym projekcie, poza tym planem.
|
|
- ai-cluster to legacy (bus martwy od 2026-06-09): wygaszany, NIE migrowany.
|
|
Branch task/ai-cluster-solaria zostaje niezmergowany jako dokumentacja reconu.
|
|
- SOLARIA jest desktopem (duty cycle ~16 h/d offline). Wszystko wymagane 24/7
|
|
mieszka na PIHA.
|
|
- CHELSTY-INFRA: fizycznie martwa, będzie reanimowana. Do tego czasu dormant.
|
|
- Approvale ZOSTAJĄ (brak gotowości na full auto). Kryterium sukcesu etapu 2:
|
|
incydent -> powiadomienie Telegram -> approve -> serwis wstaje, end-to-end.
|
|
- webui (agents.okit.pl) + materializer zostają — rola: podgląd stanu.
|
|
Telegram — rola: powiadomienia + approvale.
|
|
|
|
## Etap 0 — porządki w prawdzie (repo-only)
|
|
- CHELSTY-INFRA -> status dormant w topologii; supervisor pomija; skasować
|
|
pending redeploy ha-diag-agent.
|
|
- LUSTRO wpisać do topology.yaml (biega i raportuje, formalnie nie istnieje).
|
|
- Uzgodnić topology.yaml z hosts/*/services.yaml wg zasady: hosts autorytatywne.
|
|
- Dopisać do hosts/solaria/services.yaml to, co realnie biega (planner-agent,
|
|
stability-agent, node_exporter); los planner-agenta do decyzji przy okazji.
|
|
- Skasować martwe: scripts/deploy/deploy-role.sh, stała SERVICE_NAMES w
|
|
service_ops_worker.py, gałąź mqtt_unreachable w supervisorze.
|
|
- Adnotacja w repo: ai-cluster = legacy, wygaszany.
|
|
|
|
## Etap 1 — przywrócenie zmysłów i rąk
|
|
1. SOLARIA: override group_add na host docker gid (996) w hosts/solaria —
|
|
odblokowuje raportowanie kontenerów i wykonywanie restartów.
|
|
2. stability-agent: emitować nazwę serwisu z labela compose zamiast service=None
|
|
(wzorzec z majowego fixu node-agenta). Potem decyzja: fuzja czujników w
|
|
node-agenta i wygaszenie stability-agenta (do potwierdzenia po przeglądzie
|
|
unikalnych funkcji stability-agenta).
|
|
3. Mapowanie supervisora: healthcheck_failed -> container_restart (redeploy wraca
|
|
do mapy dopiero gdy działa).
|
|
|
|
## Etap 2 — pętla z człowiekiem
|
|
4. Naprawa redeploy: executor woła deploy przez ssh z VPS per-service;
|
|
deploy-node.sh musi honorować argumenty <node> <service>.
|
|
5. TTL na pending: 24 h -> expired, ID zwolnione, incydent może znów alarmować.
|
|
6. Telegram jako kanał approvali (approve/reject przy powiadomieniu). Nośnik:
|
|
telegram-bot z agent-systemu — w ramach tego kroku wciągnąć go do manifestów
|
|
(pierwszy element wciągania shadow setu).
|
|
7. Test końcowy etapu: kontrolowane ubicie serwisu (kandydat: gokapi, i tak
|
|
leży) -> alert Telegram -> approve -> serwis wstaje.
|
|
|
|
## Etap 3 — retencja i zakres
|
|
8. Pruning eventów: retencja per typ (health ~3 d, incydentowe ~30 d,
|
|
action_result bezterminowo), format docelowy per-event JSON, cron na VPS.
|
|
9. Deklaracja zakresu monitoringu: każdy kontener na monitorowanych nodach albo
|
|
w manifeście, albo jawnie unmanaged: true z powodem.
|
|
|
|
## Poza planem
|
|
- Wygaszenie kontenerów ai-clustra na VPS: osobna sesja (stop stacka, obserwacja
|
|
free -m, rollback = start).
|
|
- Subsystem B: osobny projekt.
|
|
|
|
Zależności: 2 wymaga 1; 7 wymaga 4-6. Kolejność etapów wiążąca, kolejność wewnątrz
|
|
etapów — nie.
|