Săriți la conținut

Blog ·

Un cuvânt de capacitate, o comandă veche

Când o rundă adaugă un câmp protobuf, un agent vechi eșuează zgomotos. Când schimbă doar înțelesul unui indicator, același agent răspunde plauzibil și greșit.

De Provibr

Agentul nostru rulează înăuntrul rețelei clientului și sună spre noi în afară. Se actualizează singur, dar nu pe loc și nu întotdeauna, așa că în orice clipă flota este o împrăștiere de versiuni, iar platforma trebuie să știe ce poate face fiecare dintre ele.

Știe fiindcă îi spune agentul. La fiecare sesiune, agentul trimite o listă de cuvinte scurte, câte unul pentru fiecare capacitate, iar platforma refuză o comandă al cărei cuvânt lipsește, în loc să o trimită și să spere.

Runda aceasta a adăugat al treilea astfel de cuvânt pentru containerele Proxmox și este primul la care întrebarea interesantă nu a fost dacă să îl adăugăm, ci ce s-ar fi întâmplat fără el.

De ce există cuvintele acestea

Mecanismul apără împotriva unei însușiri anume a lui protobuf: un câmp necunoscut dintr-un oneof este aruncat.

Când o rundă adaugă o comandă nouă drept câmp nou, un agent dinaintea rundei analizează mesajul, nu recunoaște numărul câmpului, îl scapă și rămâne cu un ProxmoxCommand fără nicio comandă înăuntru. Apoi spune exact asta. Mesajul este sincer și cu totul nefolositor: operatorul vede o plângere despre un plic gol, iar cauza se află patru straturi mai încolo, într-o nepotrivire de versiuni pe care nu a pomenit-o nimeni.

Așa că platforma refuză mai întâi. Dacă lipsește cuvântul, comanda nu pleacă niciodată, iar refuzul numește capacitatea și versiunea agentului. Este un rezultat mai prost decât o comandă care merge și unul mult mai bun decât o comandă care eșuează într-un fel ce cere o după-amiază de urmărit.

Este un eșec zgomotos în ambele feluri. Lucrul acesta se dovedește că are însemnătate.

Al treilea cuvânt nu este un câmp nou

Schimbarea rundei acesteia a fost că un container își poate arăta acum componentele. Comanda care face asta, GetHardware, nu este nouă. Fiecare agent, până la primele lucrări la ciclul de viață al mașinilor virtuale, cunoaște mesajul și știe să răspundă la el.

Ce s-a schimbat este un indicator de lângă ea, care spune la ce fel de resursă se referă identificatorul. Un agent dinaintea rundei acesteia primește indicatorul, nu îl cunoaște și îl scapă, exact așa cum spune protobuf că trebuie. Apoi face ce a făcut întotdeauna la o cerere de componente: cere de la Proxmox configurația mașinii pe calea QEMU.

Nimic nu este gol. Nimic nu se plânge. Agentul crede că i s-a pus o întrebare pe care o înțelege și răspunde.

Sunt două feluri în care asta aterizează și niciunul dintre ele nu este zgomotos. Dacă Proxmox nu are nimic la identificatorul acela pe calea mașinilor virtuale, clientului i se spune că o mașină nu există, despre un container care rulează în fața lui. Iar dacă o configurație chiar vine înapoi și este dată analizorului construit pentru mașini virtuale, răspunsul nu este gol, este greșit.

Răspunsul greșit este anume și arată bine

Cele două formate de configurație sunt destul de apropiate încât să se analizeze și destul de deosebite încât să conteze. O mașină virtuală își scrie prima placă de rețea drept model și adresă MAC unite printr-un semn de egal. Un container scrie mai întâi un nume de interfață, apoi adresa MAC într-un câmp separat, cu cheie proprie.

Analizorul pentru mașini virtuale ia prima pereche de cheie și valoare drept model și adresă. Primind linia unui container, raportează așadar o placă de rețea al cărei model este name și a cărei adresă MAC este ETH0.

Acesta este un rând care arată plauzibil într-un tabel. Are un model, are o adresă, este afișat fără nicio avertizare. Este motivul pentru care calea containerelor a avut nevoie de analizorul ei și este exact clasa de defect pe care nu îl raportează nimeni, fiindcă nu are nimic în el de raportat. Cineva se uită la un ecran, se gândește că rubrica modelului este ciudată și merge mai departe.

Așa că o comandă care există deja este un fel de schimbare mai primejdios decât o comandă nouă. Cea nouă eșuează la plic, în public. Aceasta eșuează la înțeles, în particular.

De ce nu lărgim nimic și adăugăm în schimb o linie

Alternativa evidentă este să lărgim cuvântul care există deja. Există un cuvânt care spune că agentul înțelege calea containerelor în general și ar fi fost nevoie de un singur caracter ca el să însemne și lucrul mai nou.

Asta ar refuza fiecare comandă de container de la fiecare agent care nu s-a actualizat încă, inclusiv de la cele care merg perfect astăzi. O flotă care servește chiar acum containere s-ar stinge pentru o capacitate pe care o are cu adevărat, fiindcă noi am schimbat pe dedesubt înțelesul cuvântului nostru.

Un cuvânt este o promisiune despre ce s-a construit, iar promisiunea trebuie să își păstreze înțelesul atâta vreme cât o mai ține cineva. Adăugarea unui al treilea cuvânt costă o constantă de fiecare parte și refuză exact comenzile care trebuie refuzate, și nimic altceva. Pune totodată raționamentul undeva unde îl va găsi o persoană, adică lângă constantă și nu într-un mesaj de commit.

Cele două părți sunt două constante, una în sursa Rust și una în TypeScript-ul partajat, fiecare numind-o pe cealaltă. Perechea aceasta nu este elegantă, iar orice încercare de a o face elegantă sfârșește cu un pas de construire între două limbaje care trebuie să se poată citi fiecare de la sine.

Stubul spune două din trei dinadins

Există un agent de tip stub care ne lasă să conducem gateway-ul fără un hipervizor, iar el anunță și cuvintele pentru containere.

Anunță două dintre ele. Spune că știe calea containerelor și spune că citește componentele containerelor, iar pe al treilea dinadins nu îl susține, fiindcă reinstalarea unui container este ceva ce nu poate face.

Merită spus, fiindcă un stub care susține totul este un stub care face de netestat fiecare cale de refuz. Iar opusul contează la fel de mult: fără cuvântul pentru componente, gateway-ul ar fi refuzat, pe drept, iar verificarea ar fi măsurat în tăcere un refuz în loc de un răspuns. Un banc de test care minte despre propriile capacități produce rezultate verzi despre altceva.

Ce am consemna

  1. Protobuf scapă în tăcere câmpurile necunoscute, așa că o comandă nouă ajunge la un agent vechi ca un plic gol.
  2. Refuzați înainte de a trimite. Un refuz care numește capacitatea și versiunea bate o plângere venită de patru straturi mai jos.
  3. Schimbarea fără niciun câmp nou este cea primejdioasă. Nu se scapă nimic, deci nu se plânge nimic.
  4. Felul de eșec pe care îl vreți este cel zgomotos. Un răspuns plauzibil și greșit nu vă va fi raportat niciodată.
  5. Două formate de configurație care se analizează amândouă sunt mai rele decât două care nu se analizează.
  6. Nu lărgiți niciodată un cuvânt de capacitate care există. Este o promisiune ținută de agenți la care nu puteți ajunge.
  7. Un cuvânt în plus costă o constantă de fiecare parte și refuză numai ce trebuie refuzat.
  8. Puneți raționamentul lângă constantă, acolo unde va sta cu adevărat următorul om.
  9. Un stub trebuie să refuze ce nu poate face, altfel fiecare cale de refuz ajunge de netestat.
  10. Un banc de test care susține prea mult produce rezultate verzi despre altceva.

Ca să fie limpede ce este aceasta: un al treilea cuvânt de capacitate pentru containerele Proxmox, adăugat alături de o schimbare care nu a introdus niciun câmp nou de protocol, cu raționamentul consemnat lângă amândouă constantele și cu agentul de tip stub anunțând două din trei; runda a mutat modulul de teste pentru containere de la treizeci și cinci de teste la treizeci și nouă, formatarea și ținta de release curate, și s-a încheiat cu pachetele partajate la 5347 verde, gateway-ul la 1467, uneltele de tip stub la 489 și suita web la 4593, fără niciun eșec, plus cincizeci de verificări în browser verzi în două limbi. Nedovedite: nimic de aici nu a rulat față de un Proxmox adevărat, așa că purtarea unui agent mai vechi pe un identificator de container este stabilită din cele două formate de configurație și din analizor, nu observată, iar lanțul în funcțiune a fost pus la încercare față de propriul nostru stub.

Din munca de platformă la Provibr. Ce se întâmplă când două runde ajung la același număr de câmp se află în două runde, un singur număr de câmp, runda care a învățat prima dată agentul despre containere se află în reinstalarea unui container este o înlocuire, iar felul în care un agent hotărăște dacă are încredere într-o construcție nouă se află în cum se refuză singură o actualizare semnată.

Începeți cu o gazdă și un agent

Creați un cont, instalați agentul cu o singură comandă și conectați primul dumneavoastră host Proxmox. Perioada de probă durează 14 zile și nu cere date de plată.