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>
Zastępuje gałąź feat/astroklient. Tamta była odbita od mastera sprzed jedenastu
commitów i miała przypięte obrazy `ee3c515d`, podczas gdy master stoi na
`320a0ab2` — merge w tamtej postaci COFNĄŁBY klaster o kilka wersji. Zamiast
przepychać cztery commity przez rebase (każdy konfliktował na README), gałąź
jest odtworzona jednym commitem na aktualnym masterze, z zachowanymi tagami.
ZMIANA NAZWY. astroklient-demo → astrodemo, wraz z nazwą obrazu, zmiennymi
(ASTRODEMO_USERS) i sekretem (astrololo-astrodemo). Nazwa „astroklient" jest
zarezerwowana dla warstwy pośredniej: pełne funkcje astrologiczne, bez
generowania tekstu i bez administracji.
BRAKOWAŁO WEJŚCIA Z ZEWNĄTRZ. Manifesty tworzyły Deployment i Service, ale żadnej
reguły w Ingressie — usługa wstałaby i nie dałoby się do niej wejść. Dołożony
host astrodemo.czernobog.pl z przekierowaniem z http, a certyfikat obejmuje teraz
oba hosty.
Osobny host, a nie ścieżka `/demo` pod adresem astrololo, CELOWO: ścieżka
dzieliłaby z pełną aplikacją pochodzenie w rozumieniu przeglądarki, czyli
i ciasteczka — wejście do jednej ruszałoby sesję w drugiej.
OBRAZ NA LIŚCIE OBSERWOWANYCH. Bez wpisu w image-updater.yaml obraz nigdy się nie
podbije, choćby CI go budowało. Tak przez chwilę wisiał render na :latest.
POPRAWKI W RUNBOOKU. Opis twierdził, że demo pracuje na produkcyjnej warstwie
danych — nieprawda od PRE-29, ma własny stos i własny udział. Ponadto zmiana nazw
rozjechała ścieżkę udziału: `zfs create Tank1/astrololo-astrodemo` przy manifeście
montującym `/mnt/Tank1/astrololo-demo` utworzyłby inny zbiór niż ten, którego pod
szuka. Ścieżka jest stanem na dysku, nie nazwą w kodzie — zostaje jak była.
Sprawdzone: `kubectl kustomize astrololo/` buduje 29 obiektów, tagi obrazów
pozostają na 320a0ab2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gitea