Când NetBox este sursa de adevăr

Un client cu un NetBox funcțional nu vrea un al doilea inventar. Vrea ca rackurile și mașinile lui să apară în platforma din care lucrează și vrea să le editeze în continuare în locul pe care echipa lui îl cunoaște deja.

Cuvântul pus de obicei alături de asta este „sincronizare”, iar cuvântul este problema. Sincronizarea presupune două sisteme care converg spre un singur adevăr. Ce aveți de fapt este o întrebare pentru fiecare câmp, la care trebuie răspuns dinainte și în scris: pentru coloana aceasta, pe obiectul acesta, cine hotărăște? Răspundeți o dată dând din umeri și ați construit un sistem care suprascrie o modificare locală deliberată la trei dimineața, sau unul care ignoră în tăcere o modificare pe care clientul a făcut-o acum o oră și pe care o crede ajunsă la destinație.

Iată cum am răspuns noi, inclusiv câmpurile la care răspunsul este nu.

Patru valori, și nu sunt grade de încredere

Fiecare coloană a fiecărui obiect legat poartă una dintre patru valori de proprietate, iar ele spun patru lucruri diferite despre cine hotărăște, nu patru niveluri de siguranță.

Extern. Cealaltă parte hotărăște. Câmpul este numai pentru citire aici, iar un import îl suprascrie fără să întrebe. Nu este o pierdere de control, este înțelegerea în care a intrat administratorul când a conectat sistemul.

Al nostru. Noi hotărâm, iar un import nu îl atinge. Aceasta este starea fiecărui câmp al unui obiect care nu este legat deloc și a fiecărui câmp pentru care sistemul extern nu are corespondent.

Blocat manual. Cealaltă parte chiar are o valoare, iar un administrator a suprascris-o aici în mod deliberat, cu un motiv. O diferență este atunci un conflict care este scos la suprafață, niciodată o suprascriere tăcută. Este singura dintre cele patru care nu poate apărea ca implicit: o setează cineva.

Derivat. Nu hotărăște nimeni. Decurge din altceva: dacă o mașină este în rack, dacă este legată de un serviciu, dacă este pregătită, capacitatea unui rack, contabilitatea rândului însuși. Acestea nu sunt structural importabile, iar un test afirmă că ele nu apar niciodată în vreo corespondență.

Ultima merită o notă. Câmpurile de contabilitate, cine a creat un rând și când, sunt derivate, nu ale noastre. Nimeni nu alege acele valori, ele decurg din acțiune. Un traseu de import căruia i se permite să scrie un marcaj de timp al creării este un traseu de import care poate rescrie istoria.

Proprietatea atârnă de legătură, nu de obiect. Un obiect fără legătură este în întregime al nostru, ceea ce înseamnă că desfacerea legăturii este o singură ștergere, nu o migrare de stare pe fiecare coloană.

Registrul este pe coloană, iar lista de coloane vine din schemă

Fiecare coloană a celor patru tipuri de obiecte acceptate, situri, locații, rackuri și mașini, are o intrare într-un registru. Inclusiv cele care nu au absolut nicio legătură cu sistemul extern.

Completitudinea aceea este impusă, nu doar intenționată. Un test derivă lista de coloane din schema bazei de date și cere o decizie pentru fiecare. O coloană nouă adăugată într-o rundă ulterioară este așadar un test roșu, nu o lacună tăcută, ceea ce este aceeași construcție pe care o folosim și în altă parte: un test pentru fiecare caz nu poate, prin natura lui, să găsească un caz care lipsește.

Unele dintre decizii sunt partea interesantă.

Bugetul de putere al unui rack rămâne al nostru. NetBox modelează puterea drept alimentări, nu drept o singură cifră de buget. Derivarea unui număr din mai multe alimentări ar fi o afirmație despre capacitate asamblată din date incomplete, adică exact lucrul pe care proiectarea capacității îl interzice. Așa că acest câmp nu este importat, cu propoziția aceasta consemnată alături drept motiv.

Starea de proces a unei mașini rămâne a noastră. Starea de dispozitiv din NetBox amestecă ciclul de viață și operarea într-un singur câmp. Un dispozitiv marcat drept defect ar împinge, într-o corespondență naivă, o mașină într-o stare de mentenanță și ar scoate-o din fondul vandabil. Sunt două vocabulare diferite care se întâmplă să împartă un nume.

Felul unei mașini rămâne al nostru. Rolul de dispozitiv din NetBox este text liber. Ghicirea greșită acolo nu produce o eroare cosmetică, ci schimbă ce vă lasă platforma să faceți cu o mașină.

Fiecare dintre acestea este stocată cu un motiv scris, în aceeași structură cu decizia. O regulă cu un motiv atașat supraviețuiește următoarei persoane; o regulă fără unul este relaxată de cineva care presupune că a fost arbitrară.

Numai la început, pentru că există autocolante într-o cutie

Două câmpuri sunt importate o singură dată, la creare, și nu mai sunt actualizate niciodată: codul unui sit, al unei locații sau al unui rack, și codul de inventar al unei mașini.

Motivul este fizic. Valorile acelea sunt tipărite pe etichete, iar etichetele sunt într-o cutie într-un dulap. Un slug redenumit în NetBox primăvara viitoare nu are voie să trimită o scanare în locul greșit. Numai la început nu este o a treia valoare de proprietate, este o proprietate a importului: luați-o la adăugare, lăsați-o în pace după aceea.

Aceleași câmpuri sunt cele după care este potrivit un obiect nelegat atunci când conexiunea se face prima dată: codul pentru celelalte trei, codul de inventar pentru mașini. Deliberat nu numele, pentru că un cod este stabil și unic indiferent de majuscule, iar un nume nu este niciuna dintre acestea.

Amplasarea nu este niciodată importată și nu există câmp care să ducă acolo

NetBox cunoaște, pentru fiecare dispozitiv, rackul, poziția și fața lui. Cele trei sunt refuzate.

Nu ignorate. Refuzate, pe nume, cu un cod de motiv, și arătate în previzualizare.

Raționamentul decurge direct din proiectarea ocupării: singura limită reală a ocupării unui rack este un index unic parțial pe tabelul de sloturi, iar acel index este atins vreodată de o singură funcție. Un traseu de import care scrie un rack și un număr de unitate pe o mașină este un al doilea traseu de scriere care nu știe de acel index, și atunci într-o zi o mașină este înregistrată în două rackuri, cu un sistem extern care confirmă că așa este corect.

Specificația acestei secțiuni spune că o amplasare locală sau o revendicare activă nu are voie să fie ștearsă niciodată de un import. Există două feluri de a face asta adevărat. Unul este să scrieți importul astfel încât să lase revendicările în pace. Celălalt este să faceți imposibil ca importul să scrie vreo revendicare, iar pe acesta l-am ales: nu există câmp care să ducă acolo.

Impunerea lui este o gardă pe arborele sintactic abstract, nu un caz de test. Ea citește sursa modulului de import și cere ca cele patru tabele protejate, revendicările, sloturile, legăturile de serviciu și etichetele, să apară numai într-un select. Un insert, un update sau un delete pe oricare dintre ele este roșu chiar dacă niciun traseu de cod nu ajunge vreodată acolo, pentru că garanția trebuie să țină și pentru cod care încă nu există. Parcurgătorul eșuează zgomotos la o formă pe care nu o recunoaște, lecție învățată scump la o gardă anterioară care sărea în tăcere peste ce nu putea analiza.

Refuzurile sunt enumerate pe nume în previzualizare. Omisiunea tăcută este varianta periculoasă aici: cineva își conectează NetBox-ul, citește „142 de mașini actualizate” și presupune că a venit și aranjarea rackurilor odată cu el.

O ștergere externă este un tombstone

Un obiect legat pe care cealaltă parte încetează să îl mai menționeze devine un tombstone cu o analiză de impact, nu o ștergere.

Asta nu este doar politețe. O listă care se întoarce scurtă din cauza unei greșeli de filtru, a unei schimbări de permisiuni sau a unei pagini luate pe jumătate ar goli altfel inventarul unui client. Tombstone-ul pune obiectul în fața unui om, împreună cu ce depinde de el: un obiect cu o revendicare activă nu poate fi înlăturat deloc, iar după ce revendicarea este eliberată, rezultatul este o scoatere din uz, nu o ștergere.

Iar dacă se știe că preluarea este trunchiată, nu se întâmplă absolut nimic. Nu se propune niciun tombstone pentru nimic. Ce nu ați văzut nu puteți conchide că lipsește. Este o condiție de două linii și este diferența dintre un conector și un incident.

Ce am nota

1. 01Hotărâți proprietatea pe coloană, nu pe obiect, și faceți lista de coloane să vină din schemă, ca una nouă să nu poată fi uitată.
2. 02Stocați motivul odată cu decizia. Un câmp care nu este importat are nevoie de o propoziție, altfel îl va importa cineva mai târziu.
3. 03Faceți importul periculos imposibil, nu atent. Niciun câmp către el, plus o gardă care citește sursa.
4. 04Numiți în previzualizare ce refuzați, pentru că un număr de obiecte actualizate se citește drept completitudine.
5. 05Tratați absența drept o întrebare, niciodată drept o ștergere, și tratați o preluare trunchiată drept nicio informație.

Despre starea noastră: asta se află în spatele unui indicator de lansare oprit implicit, cu o setare pentru fiecare organizație peste el, așa că nu este ceva de cumpărat astăzi, și nu a rulat împotriva unui NetBox real. Ce se spune mai sus despre felul în care NetBox modelează puterea, starea și rolurile vine din documentația lui și din forma interfeței sale, nu dintr-o instanță de producție. Tot ce este mai sus a fost măsurat față de un stub care reproduce comportamentul de paginare, antetul de versiune și obiectele imbricate ale interfeței reale, fixat pe versiunea de API pe care o trimite codul de producție. Stubul chiar oferă un rack, o poziție și o față în sarcinile utile ale dispozitivelor sale, iar zero revendicări sunt scrise: refuzul este măsurat, nu presupus. Întrebarea înrudită, de ce un sistem extern care raportează succes nu este un rezultat în sine, se află în de ce un 200 de la Proxmox nu este un rezultat.

Din munca la centrul de date de la Provibr. Granița de ocupare de care este ținut departe acest import este descrisă în singura limită reală a ocupării unui rack, iar etichetele ale căror coduri trebuie să rămână stabile în o etichetă care supraviețuiește unei redenumiri.