data: wymagaj węzła z x86-64-v2 + runbook maskowania CPU #25

2026-08-26T19:44:04Z

gitea commented

2026-08-26 19:44:04 +00:00

⚠️ ZANIM ZMERGUJESZ

Oznacz węzły, inaczej data pójdzie w Pending. Dziś etykietę ma zero węzłów:

for N in k3s-server k3s-agent1 k3s-agent2; do
  kubectl label node $N astrololo.czernobog.pl/cpu-x86-64-v2=true
done

k3s-agent3 celowo pomijamy — dopóki nie dostanie --cpu host, nie może uruchamiać warstwy danych.

Co się stało

data-demo wpadał w pętlę restartów na agent3:

RuntimeError: NumPy was built with baseline optimizations:
(X86_V2) but your machine doesn't support: (X86_V2).

To nie jest różnica sprzętu

Zmierzone na żywo, na wszystkich czterech węzłach:

węzeł	procesor widziany przez gościa	x86-64-v2	wiek
k3s-server	QEMU Virtual CPU 2.5+	TAK	52 dni
k3s-agent1	QEMU Virtual CPU 2.5+	TAK	52 dni
k3s-agent2	QEMU Virtual CPU 2.5+	TAK	52 dni
k3s-agent3	Common KVM processor	NIE — brak `popcnt ssse3 sse4_1 sse4_2`	14 dni

Wszystkie cztery to maszyny wirtualne. Fizyczny i7-3770 obsługuje nawet x86-64-v3 — te flagi są maskowane przez domyślny model CPU w Proxmoksie (kvm64). Stąd złudzenie „trzech różnych procesorów": ten sam sprzęt, różne maski.

agent3 jest o 38 dni młodszy od reszty. Przy jego zakładaniu pominięto krok --cpu host, odnotowany w pamięci projektu 2 sierpnia. Nikt tego nie zauważył, bo data to jedyna usługa ciągnąca pandas — astrodemo, logic-demo i render stoją na agent3 bez problemu.

Naprawa u źródła

qm set <VMID> --cpu host
qm stop <VMID> && qm start <VMID>

Sam restart z wnętrza gościa nie wystarczy — zmiana modelu CPU wchodzi dopiero przy pełnym wyłączeniu i włączeniu. Zastrzeżenie: --cpu host blokuje migrację na żywo między hostami o różnych procesorach; przy migracjach właściwy jest wspólny mianownik x86-64-v2-AES.

Dlaczego etykieta, a nie wykluczenie agent3

Wykluczenie po nazwie znaczyłoby, że każdy kolejny źle postawiony węzeł znów zbierze się przez awarię. Etykieta odwraca domyślną odpowiedź: nowy węzeł nie dostaje warstwy danych, dopóki ktoś go nie sprawdzi. To ta sama klasa błędu co lista hostów NFS i lista obserwowanych obrazów — coś dołącza do klastra i nic nie zauważa, że nie jest gotowe.

Pułapka przy czytaniu flag

Linux raportuje SSE3 jako pni, nie sse3. Pierwsza wersja mojej kontroli wskazała przez to trzy zdrowe węzły jako niesprawne — poprawione i udokumentowane w runbooku, żeby nie powtórzyć.

Przy okazji

Lista węzłów w eksportach NFS obejmuje teraz wszystkie cztery (runbooki wymieniały trzy) — dług z wcześniejszej sesji.

## ⚠️ ZANIM ZMERGUJESZ Oznacz węzły, inaczej `data` pójdzie w **Pending**. Dziś etykietę ma **zero** węzłów: ```bash for N in k3s-server k3s-agent1 k3s-agent2; do kubectl label node $N astrololo.czernobog.pl/cpu-x86-64-v2=true done ``` `k3s-agent3` **celowo pomijamy** — dopóki nie dostanie `--cpu host`, nie może uruchamiać warstwy danych. ## Co się stało `data-demo` wpadał w pętlę restartów na agent3: ``` RuntimeError: NumPy was built with baseline optimizations: (X86_V2) but your machine doesn't support: (X86_V2). ``` ## To nie jest różnica sprzętu Zmierzone na żywo, na wszystkich czterech węzłach: | węzeł | procesor widziany przez gościa | x86-64-v2 | wiek | |---|---|---|---| | k3s-server | QEMU Virtual CPU 2.5+ | **TAK** | 52 dni | | k3s-agent1 | QEMU Virtual CPU 2.5+ | **TAK** | 52 dni | | k3s-agent2 | QEMU Virtual CPU 2.5+ | **TAK** | 52 dni | | k3s-agent3 | **Common KVM processor** | **NIE** — brak `popcnt ssse3 sse4_1 sse4_2` | **14 dni** | Wszystkie cztery to maszyny wirtualne. Fizyczny i7-3770 obsługuje nawet x86-64-**v3** — te flagi są **maskowane** przez domyślny model CPU w Proxmoksie (`kvm64`). Stąd złudzenie „trzech różnych procesorów": ten sam sprzęt, różne maski. agent3 jest o 38 dni młodszy od reszty. Przy jego zakładaniu pominięto krok `--cpu host`, odnotowany w pamięci projektu 2 sierpnia. Nikt tego nie zauważył, bo `data` to **jedyna** usługa ciągnąca pandas — astrodemo, logic-demo i render stoją na agent3 bez problemu. ## Naprawa u źródła ```bash qm set <VMID> --cpu host qm stop <VMID> && qm start <VMID> ``` Sam restart z wnętrza gościa **nie wystarczy** — zmiana modelu CPU wchodzi dopiero przy pełnym wyłączeniu i włączeniu. Zastrzeżenie: `--cpu host` blokuje migrację na żywo między hostami o różnych procesorach; przy migracjach właściwy jest wspólny mianownik `x86-64-v2-AES`. ## Dlaczego etykieta, a nie wykluczenie agent3 Wykluczenie po nazwie znaczyłoby, że **każdy kolejny źle postawiony węzeł znów zbierze się przez awarię**. Etykieta odwraca domyślną odpowiedź: nowy węzeł nie dostaje warstwy danych, dopóki ktoś go nie sprawdzi. To ta sama klasa błędu co lista hostów NFS i lista obserwowanych obrazów — coś dołącza do klastra i nic nie zauważa, że nie jest gotowe. ## Pułapka przy czytaniu flag **Linux raportuje SSE3 jako `pni`**, nie `sse3`. Pierwsza wersja mojej kontroli wskazała przez to trzy zdrowe węzły jako niesprawne — poprawione i udokumentowane w runbooku, żeby nie powtórzyć. ## Przy okazji Lista węzłów w eksportach NFS obejmuje teraz wszystkie cztery (runbooki wymieniały trzy) — dług z wcześniejszej sesji.

gitea added 1 commit 2026-08-26 19:44:04 +00:00

data: wymagaj węzła z x86-64-v2; runbook maskowania CPU i lista czterech węzłów eff9d206ac

data-demo wpadał w pętlę restartów na k3s-agent3:

  RuntimeError: NumPy was built with baseline optimizations:
  (X86_V2) but your machine doesn't support: (X86_V2).

DIAGNOZA — to NIE jest różnica sprzętu. Wszystkie cztery węzły to maszyny
wirtualne. Trzy widzą procesor jako „QEMU Virtual CPU 2.5+" i mają komplet
rozszerzeń x86-64-v2; agent3 widzi „Common KVM processor" (kvm64) i nie ma
popcnt, ssse3, sse4_1 ani sse4_2. Fizyczny i7-3770 pod spodem obsługuje nawet
x86-64-v3 — te flagi są MASKOWANE przez domyślny model CPU w Proxmoksie.

agent3 ma 14 dni, pozostałe 52. Został dołożony później i pominięto przy nim
krok `--cpu host`, odnotowany w pamięci projektu 2 sierpnia. Nikt tego nie
zauważył, dopóki scheduler nie postawił tam akurat warstwy danych — jedynej,
która ciągnie pandas, a przez nią NumPy.

ZABEZPIECZENIE: data i data-demo wymagają etykiety
`astrololo.czernobog.pl/cpu-x86-64-v2`. Świadomie ETYKIETA, a nie wykluczenie
agent3 po nazwie: wykluczanie po nazwie znaczyłoby, że każdy KOLEJNY źle
postawiony węzeł znów zbiera się przez awarię. Nowy węzeł jest domyślnie
nieoznaczony, więc nie dostanie tych podów, dopóki ktoś go nie sprawdzi
i nie oznaczy. Pending z czytelnym powodem bije pętlę restartów z komunikatem
o „baseline optimizations".

KOLEJNOŚĆ: węzły trzeba oznaczyć PRZED wdrożeniem tej zmiany. Dziś etykietę ma
zero węzłów, więc samo zmergowanie posłałoby data w Pending.

RUNBOOK: skrypt sprawdzający węzły, naprawa u źródła (`qm set --cpu host` plus
pełne wyłączenie i włączenie maszyny — sam restart z gościa nie wystarcza),
oraz zastrzeżenie, że `--cpu host` blokuje migrację na żywo między hostami
o różnych procesorach.

PUŁAPKA PRZY CZYTANIU FLAG, udokumentowana bo kosztowała fałszywą diagnozę:
Linux raportuje SSE3 jako „pni", nie „sse3". Pierwsza wersja kontroli wskazała
przez to trzy zdrowe węzły jako niesprawne.

Przy okazji: lista węzłów w eksportach NFS obejmuje wszystkie cztery. Runbooki
wymieniały trzy, a klaster ma cztery — ten sam mechanizm, ta sama przyczyna.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

gitea merged commit eff9d206ac into master

2026-08-26 21:10:53 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/deploy#25