Rozstrzygniecie 1. Monolit mieszal cztery typy OKF. Rozbity PER TYP po
granicy sekcji `##`:
10 x decision — pozycje backlogu (w tym backlog-aktywne 28 KB
i backlog-zamkniete 12 KB, ktore zostaja calosciami)
7 x incident — bugi/awarie dotad wtopione w backlog: cutover HA ken,
checkpoint observera, ha-diag-agent node=unknown,
deploy-local ghost-kontenery, paperless-worker config,
deploy-node nie przebudowuje obrazu, ollama bez sterownika
2 x phase — HA configs-as-code, monitoring floty Prometheus
kb/phases/backlog.md zostaje jako cienki indeks (type: phase, status: active):
oryginalna preambula + wygenerowany spis linkow do wszystkich 19 elementow.
23 przychodzace odwolania zostaja przepiete na ta sciezke w grupie 7.
NIE rozbijano po `###` (38 pozycji w "Aktywne" + 13 w "Zamkniete" = 51
plikow). Rozstrzygniecie mowi "rozbij per typ", a nie per pozycja;
rozdrobnienie do 51 plikow rozerwaloby czytelnosc backlogu.
Kontrola: preambula + 19 sekcji == oryginal z HEAD (multizbior niepustych
linii). Tresc pozycji nietknieta.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.8 KiB
2.8 KiB
| okf | type | visibility | status | updated | links | |
|---|---|---|---|---|---|---|
| 0.1 | incident | private | active | 2026-08-03 |
|
Fix: paperless-worker@SOLARIA — dwa bugi configu, naprawione i zweryfikowane na żywo (2026-07-12)
Kontekst. Moduł 3 (services/paperless-worker/, split-host OCR worker) był
zdeployowany i brał zadania z kolejki, ale miał dwa bugi w compose:
command: celery ...nie odpalał celery. Obraz paperless-ngx (/sbin/docker-entrypoint.sh) routuje każdy argument NIE zaczynający się od/domanage.py— więccelerylądował jako nieznana subkomenda Django, nie jako program. Fix:command: /usr/sbin/gosu paperless /usr/local/bin/celery ...(ścieżka absolutna wchodzi w gałąźexec "$@"entrypointu;gosu paperlessz przodu bo ta gałąź nie dostaje automatycznego gosu, inaczej proces poszedłby jako root i zepsuł właściciela plików na NFS).- Brak współdzielonego
SCRATCH_DIR. Paperless@PIHA staguje wgrywany plik w/tmp/paperless(domyślnySCRATCH_DIR) i niesie tę ścieżkę w payloadzie zadania celery jako ścieżkę absolutną. Worker@SOLARIA miał własny, lokalny/tmp/paperless— gdy odbierał zadanie zamiast workera PIHA, padałCannot consume ...: File not found. Fix: NFS volumepaperless_scratch(ten sam wzorzec codata/media/consume) na/opt/homelab/data/paperless/scratch(już istniał na PIHA,chown 1000:1000), mount na/tmp/paperlesspo obu stronach.
Oba fixy + uzasadnienie: services/paperless/docker-compose.yml,
services/paperless-worker/docker-compose.yml, services/paperless-worker/README.md.
Zweryfikowane end-to-end na żywo (branch task/paperless-worker-fix, jeszcze
niezmergowany do master w momencie pisania tego wpisu): 3 dokumenty testowe
wrzucone do consume/ na PIHA, jeden odebrany i dokończony przez worker@SOLARIA
(log: ocrmypdf/tesseract → ConsumeTaskPlugin completed with: Success),
zero File not found. Dokumenty testowe usunięte po teście (document.delete()
- ręczny cleanup plików) — produkcyjne 6 dokumentów nietknięte.
Otwarte (świadomie odłożone, nie blokuje działania):
hosts/solaria/services.yamliinventory/topology.yamlnie mają wpisupaperless-worker(SOLARIA ma tam tylkonode-agent) — było zaplanowane w cutover checkliście README jako krok "przy deployu", ale nigdy nie zrobione. Bez tego wpisu supervisor/observer nie widzą tego serwisu w desired-state — drift (np. worker padnie i nie wstanie) nie zostanie automatycznie wykryty przez agent system, tylko przez brak przetwarzania kolejki.- Test formalnego fallbacku (stop worker@SOLARIA → kolejka mieli na PIHA → start → drenaż) nie był wykonany w tej sesji — mechanizm nie zmienił się tym fixem (był już OK), ale warto zweryfikować przy okazji.