2025-08-28_3_revenge_of_the_slurm#

Vi sätter målet först: i morgon är vår egna dealdline för att visa en fungerande demo. Det är mer värdefullt för helheten än att vi i dag vinner alla tekniska slag i koden. Därför väljer vi att rulla tillbaka till en version som bevisligen fungerade, och får i framtiden återinföra delar av den nya funktionaliteten med den kapitelindelade felsökningen med mera.

Denna journal dokumenterar de 5+ timmar av systematisk felsökning vi gjorde: vad som krånglade, vad vi provade, varför det ibland såg rätt ut men ändå betedde sig fel, och till slut beslutet att backa till en tidigare version som fungerade. Här finns även tydliga nästa steg så att vi kan återföra förbättringar senare — men på ett säkert sätt.

Största förlusten: 22 adderade manuella triggningar av träning via frontend av utvecklaren själv, från 33 till 55. Ej önskvärt då vi vill de ska komma från externa besökare. Nu blev det nästan hälften fyllt med vad som i praktiken är en failure-counter för antal icke-fungerande lösningar som prövades - för mer faktisk prod hade det varit skäligt att manuellt snygga till detta och att även köra testerna på en replika av aktuell VM, men tjänar här som en note-to-self. Merparten av triggers görs efter ombyggen då huvudfelen relateras till utmaningarna i användarrättigheter för slurm workers inuti kubernetes respektive fastapi och de delade ytor som behöver nås av de olika delarna av systemet, där allt orkestreras och behöver skapas korrekt via docker compose - tidsbrist fick ge efter till förmån för återställande av tidigare kod för fastapi+kubernetes+docker+postgresql+slurm-delarna.

Later addition: Ändringarna vi gjorde konfliktar åter igen med det oväntade mönstret för uid och gid vilket gör testning på icke ubuntu-22.04-baserade system nära nog värdelös, och att byta ut os på vm är i dagsläget inte aktuellt - se felsökningsresultaten och writeup från 2025-06-12 angående separata slurm kluster där vi först identifierade diskrepansen mellan ubuntu22.04 och ubuntu24.04 sett till skapandet för gid och uid för docker-container-initierade users – note to self om att gå tillbaka till nya mönstren; mer felsökande online visar att grunden är skillnader i adduser paketet där ändringar i lite daemons från 24.04 har regler där gid oc uid vare sig måste vara desamma eller följa viss ordning (testa i framtiden något fast högt, typ 1551 1551 i stället för testerna med 1000 direkt).

Symptom och första hypoteser#

  • Frontend visade “Dispatch process failed” eller bara tickade upp “Manual training count”.

  • Slurm‑jobbloggar (/data/logs/ml_train_*.out/.err) visade:

    • “ModuleNotFoundError: No module named ‘app’” (importproblem)

    • Eller så “försvann” jobben ur kön direkt (PD → borta), utan tydliga artefakter.

  • Statusen i UI fastnade i “Running…” eller “Dispatch process failed”.

Initial hypotes: mismatch mellan kodsync och modulstruktur. Nya koden importerade from app.config import settings, vilket kräver att app/ finns i PYTHONPATH. Tidigare fungerande mönster körde träningsfilen direkt och läste env (behövde ingen paketimport).

Åtgärdsspår 1 — Kodsynk, sbatch och PYTHONPATH#

Mål: få importerna att fungera med modulstrukturen.

  • Kodsynk: ändrade så att hela src/ synkas till /data/app_code_for_slurm/ (därmed /data/app_code_for_slurm/app/ finns).

  • sbatch: bytte körning från filväg till modul (python -m app.ml_train) och satte PYTHONPATH=/data/app_code_for_slurm; cd in i kodroten innan körning.

  • Lagt till kapitelindelad logg (CHAPTER 1–5) i sbatch för maximal diagnos.

  • Lagt sanity‑import av “app” innan körning och robust felutskrift.

Resultat: loggarna blev mycket tydligare, men andra hinder uppstod.

Åtgärdsspår 2 — Rättigheter på /data och “Permission denied”#

Vi stötte på “Permission denied” i /data/app_code_for_slurm vid sync.

  • FastAPI‑entrypoint och Slurm‑entrypoint uppdaterades att på start:

    • chown/chmod /data (inkl. app_code_for_slurm, logs, models) till respektive runtime‑användare samt fallback a+rwX.

    • Syfte: normalisera bind‑mountens ägarskap vid containerstart.

Resultat: sync fungerade igen och loggarna landade stabilt.

Åtgärdsspår 3 — sbatch/Slurm‑hälsa och falsklarm#

  • Tidigt falsklarm: “sbatch not found” trots /usr/bin/sbatch. Fix: deterministisk check command -v sbatch.

  • Slurmcontroller: la in scontrol ping‑hälsokoll och synliga statussteg i DB.

Åtgärdsspår 4 — Scheduler och “Running…” som aldrig återställdes#

  • Prod körde extern scheduler‑container som restartade → ingen periodisk reset av TrainingStatus → “Running…” hängde kvar även när jobben var borta.

  • Åtgärd: återgick till intern scheduler i FastAPI (som i den tidigare fungerande versionen). Lade även till “Slurmstatus”‑widget i UI.

Åtgärdsspår 5 — Diagnostikverktyg#

För att göra felsökning snabb och “kapitelbaserad”:

  • scripts/build_prod_with_logs.sh: kapitelindelad build‑logg (miljö, compose config, build output, images, next steps).

  • scripts/runtime_diag_prod.sh: samlar containers/Slurm‑hälsa och loggtails till en tidsstämplad fil.

  • scripts/bug_hunting_tui.sh: TUI som bygger en komplett felsökningsmapp under tmp/bug_hunting_<ts>/ med:

    • compose configs, docker ps/images

    • Slurm: scontrol ping, sinfo, squeue

    • fastapi/scheduler/slurm‑loggar (tailade)

    • jobbloggar (senaste N)

    • env‑snapshots (sanerade)

    • skrivprober i /data från alla containers

    • SUMMARY.txt och HIGHLIGHTS.txt (sv/eng felmönster)

Åtgärdsspår 6 — Import fallback i träningskoden#

  • ml_train.py: lades till fallback om from app.config import settings misslyckas.

    • Vid fail skapas ett minimalt settings‑objekt från env, så att filkörning fortfarande fungerar.

  • sbatch: om modulkörning fallerar på import, fallback till filkörning.

Resultat: instabilt. ‘Fungerar-ibland-problem’ är sällan värda att lösa. Det kvarstod funktionella skillnader mot den gamla fungerande koden.

Beslut — tillförlitlighet framför perfektion (rollback)#

Efter flera timmars metodisk felsökning valde vi att backa till den version (“snapshot”) som fungerade hos oss tidigare:

  • Bytte hela src/app/ till backupens kod.

  • Bytte Dockerfile, docker-compose.yml, prod-docker-compose.yaml, slurm-image/Dockerfile, slurm-image/entrypoint.sh, fastapi_entrypoint.sh till backupens versioner.

  • Lät dokumentationsdelen (MkDocs) vila temporärt: tog bort dess tjänst i prod‑compose så den inte blockerar runtime.

Motivering:

  • Vi behöver en fungerande demo i morgon. Att leverera något som fungerar är mer värt än att vi vinner teknikmatchen i dag.

  • Den fungerande snapshotten låg närmast vår instrumentaliserade driftmiljö och gav förutsägbar körning.

Verifiering efter rollback#

  • Containers “healthy”.

  • Manuell träning går igenom, jobbloggar skrivs.

  • Status uppdateras korrekt (Idle efter körning) och historik hämtas.

  • Slurm controller rapporterar UP; squeue visar arbete när det ska, och “försvinner” när jobbet är klart.

Lärdomar (tekniska)#

  • Modul vs filkörning: välj EN väg — och gardera för fallback om det är kritisk drift. Korsberoenden ska dokumenteras med “invarians” (t.ex. PYTHONPATH, cwd).

  • Bind‑mount‑rättigheter är ett vanligt driftstopp. Undersök bättre mönster för ägarskap/rättigheter deterministiskt i entrypoint.

  • Slurm‑hälsa ska alltid läsas “på riktigt” (scontrol/sinfo/squeue) - när loggar inte skrivs korrekt är de en usel felkälla.

  • En “jobblogg med kapitel” är ovärderlig vid drift; men bara när loggarna skrivs tillförligt..

  • Scheduler: intern i FastAPI är enklare och säkrare tills extern är stabil - mindre elegant..

  • Dokumentation ska inte stoppa runtime (särskild pipeline/profil för MkDocs).

Nästa steg (kontrollerad återintroduktion av förbättringar)#

  1. Återinför modul‑körning och kodsynk i små steg bakom feature‑flagg, med fallback kvar.

  2. Behåll/utöka CHAPTER‑loggarna och sanity‑check i sbatch; gör ett “golden path” runt /data invariants och enhetliga UID/GID.

  3. Lägg till integrations‑checklistor i CI (syntetiskt squeue/sinfo, skrivprober på /data).

  4. Återaktivera extern scheduler först när loggar visar att den är stabil; annars kör internt.

  5. MkDocs: rensa “dead links” (t.ex. app.scheduler_service) och dela upp docs‑bygget i separat steg/profil.

Appendix — Kommandoreferens (vid felsökning)#

  • Slurm:

    • scontrol ping, sinfo, squeue -o "%i %t %M %R %j"

  • Snabbloggar:

    • head -n 120 $(ls -1t persistent-data/logs/ml_train_*.out | head -n1)

    • head -n 120 $(ls -1t persistent-data/logs/ml_train_*.err | head -n1)

  • Volymer & rättigheter:

    • ls -ld persistent-data persistent-data/*

    • sudo chown -R $(id -u):$(id -g) persistent-data

  • Bygg/runtime (prod):

    • HOST_UID=$(id -u) HOST_GID=$(id -g) docker compose -f prod-docker-compose.yaml build --no-cache

    • HOST_UID=$(id -u) HOST_GID=$(id -g) docker compose -f prod-docker-compose.yaml up -d

  • Våra skript:

    • scripts/build_prod_with_logs.sh → persistent-data/logs/build_prod_<ts>.log

    • scripts/runtime_diag_prod.sh → persistent-data/logs/runtime_diag_<ts>.log

    • scripts/bug_hunting_tui.sh → tmp/bug_hunting_<ts>/SUMMARY.txt, HIGHLIGHTS.txt