- Spegnimento
- 7 agosto 2026 alle ore 07:48 UTC
- Autore
- Kamo
- Impegno
- e853649
Stesso difetto di embedding-model, trovato controllando ogni volume hostPath nel repo. A hostPath è node-local e nulla lo replica, quindi un pod non piegato può essere programmato dove i suoi dati non lo sono. Tutti e quattro si sono mossi o sono stati a rischio di muoversi quando k3m1 è entrato. postgres-analytics è quello che importato: DirectoryOrCreate non manca su un percorso mancante, crea uno vuoto, e postgres avrebbe corso initdb in esso. Un reschedule non avrebbe hanno bloccato -- avrebbe servito analytics una storia di analisi vuota mentre il reale 67MB alloggiato su k1m1. Verificato intatto dopo pinning: 18 tavoli, 2655 eventi. qdrant è pinned a k3m1 piuttosto che k1m1 perché questo è dove i suoi dati dal vivo è. Si è mosso quando k3m1 si unì, silenziosamente ottenuto un negozio fresco, e la collezione kb è stata scritta lì da; k1m1 detiene ancora un'istantanea di marzo, quindi l'invio della capsula "casa" avrebbe tranquillamente servito vettori di quattro mesi. Passa anche a Recreate: qdrant detiene un'esclusiva WAL lock, quindi un pod di sovratensione che condivide la directory va in panico con `Can't init WAL: Il rollout non potrebbe mai finire. Quello era latente... qualsiasi urto di immagine l'avrebbe colpito. bergamotto e libretranslate hanno solo ri-scaricato i loro modelli sul nuovo nodo, motivo per cui nessuno ha notato; il commento di libretranslate ha affermato che entrambe le repliche erano su k1m1, e il pin rende ancora più vero invece di lasciare 9.7GB duplicato su k3m1.