Quando NetBox è la fonte di verità

Un cliente con un NetBox che funziona non vuole un secondo inventario. Vuole che i suoi rack e le sue macchine compaiano nella piattaforma da cui opera, e vuole continuare a modificarli nel posto che la sua squadra già conosce.

La parola che di solito si attacca a questo è «sincronizzazione», e la parola è il problema. Sincronizzare implica due sistemi che convergono su una sola verità. Quello che si ha davvero è una domanda per campo a cui bisogna rispondere in anticipo e per iscritto: per questa colonna, su questo oggetto, chi decide? Vi si risponda una volta con un’alzata di spalle e si è costruito un sistema che alle tre di notte sovrascrive una modifica locale deliberata, oppure uno che ignora in silenzio una modifica che il cliente ha fatto un’ora fa e crede sia arrivata.

Ecco come abbiamo risposto, compresi i campi in cui la risposta è no.

Quattro valori, e non sono gradi di fiducia

Ogni colonna di ogni oggetto collegato porta uno di quattro valori di titolarità, e dicono quattro cose diverse su chi decide anziché quattro livelli di fiducia.

Esterno. Decide l’altra parte. Il campo qui è di sola lettura e un’importazione lo sovrascrive senza chiedere. Non è una perdita di controllo, è l’accordo in cui l’amministratore è entrato quando ha collegato il sistema.

Nostro. Decidiamo noi, e un’importazione non lo tocca. È lo stato di ogni campo di un oggetto che non è collegato affatto, e di ogni campo per cui il sistema esterno non ha una controparte.

Bloccato manualmente. L’altra parte un valore ce l’ha, e un amministratore lo ha deliberatamente sovrascritto qui, con una motivazione. Una differenza è allora un conflitto che viene fatto emergere, mai una sovrascrittura silenziosa. È l’unico dei quattro che non può nascere come impostazione predefinita: qualcuno lo imposta.

Derivato. Non decide nessuno. Discende da qualcos’altro: se una macchina sia in rack, se sia associata a un servizio, se sia pronta, la capacità di un rack, la contabilità della riga stessa. Sono strutturalmente non importabili, e un test afferma che non compaiono mai in alcuna mappatura.

Quest’ultimo merita una nota. I campi di contabilità, chi ha creato una riga e quando, sono derivati anziché nostri. Quei valori non li sceglie nessuno, discendono dall’azione. Un percorso di importazione a cui è consentito scrivere un timestamp di creazione è un percorso di importazione che può riscrivere la storia.

La titolarità è appesa al collegamento anziché all’oggetto. Un oggetto senza collegamento è interamente nostro, il che significa che scollegare è una singola cancellazione anziché una migrazione di stato su ogni colonna.

Il registro è per colonna, e l’elenco delle colonne viene dallo schema

Ogni colonna dei quattro tipi di oggetto supportati, siti, ubicazioni, rack e macchine, ha una voce in un registro. Comprese quelle che non hanno assolutamente nulla a che fare con il sistema esterno.

Quella completezza è imposta anziché auspicata. Un test ricava l’elenco delle colonne dallo schema del database e pretende una decisione per ciascuna. Una nuova colonna aggiunta in un giro successivo è quindi un test rosso anziché una lacuna silenziosa, che è la stessa costruzione che usiamo altrove: un test per caso non può, per sua natura, trovare un caso che manca.

Alcune delle decisioni sono la parte interessante.

Il budget di potenza di un rack resta nostro. NetBox modella l’alimentazione come linee, non come una singola cifra di budget. Ricavare un numero da più linee sarebbe un’affermazione di capacità messa insieme con dati incompleti, che è precisamente la cosa che il progetto della capacità vieta. Il campo quindi non viene importato, con quella frase registrata accanto come motivazione.

Lo stato di processo di una macchina resta nostro. Lo status di un device in NetBox mescola ciclo di vita e operatività in un solo campo. Un device contrassegnato come guasto spingerebbe, in una mappatura ingenua, una macchina in uno stato di manutenzione e la toglierebbe dal bacino vendibile. Sono due vocabolari diversi che per caso condividono un nome.

Il tipo di una macchina resta nostro. Il device role di NetBox è testo libero. Indovinare male lì non produce un errore estetico, cambia ciò che la piattaforma consente di fare con una macchina.

Ciascuna di queste è memorizzata con una motivazione scritta, nella stessa struttura della decisione. Una regola con una motivazione attaccata sopravvive alla persona successiva; una regola senza motivazione viene allentata da qualcuno che presume fosse arbitraria.

Solo alla creazione, perché in una scatola ci sono degli adesivi

Due campi vengono importati una volta, alla creazione, e mai aggiornati: il codice di un sito, di un’ubicazione o di un rack, e l’asset tag di una macchina.

Il motivo è fisico. Quei valori sono stampati su etichette, e le etichette stanno in una scatola in un ripostiglio. Uno slug rinominato in NetBox la primavera prossima non deve mandare una scansione nel posto sbagliato. Solo alla creazione non è un terzo valore di titolarità, è una proprietà dell’importazione: si prende quando si aggiunge, la si lascia stare dopo.

Gli stessi campi sono quelli su cui viene abbinato un oggetto non collegato quando il collegamento viene stabilito la prima volta: il codice per gli altri tre, l’asset tag per le macchine. Di proposito non il nome, perché un codice è stabile e univoco a prescindere dalle maiuscole e un nome non è né l’uno né l’altro.

La collocazione non viene mai importata, e non c’è alcun campo che ci porti

NetBox conosce, per ogni device, il suo rack, la sua posizione e il suo lato. Quei tre vengono rifiutati.

Non ignorati. Rifiutati, per nome, con un codice di motivo, e mostrati nell’anteprima.

Il ragionamento discende dritto dal progetto dell’occupazione: l’unico limite reale all’occupazione di un rack è un indice univoco parziale sulla tabella degli slot, e quell’indice lo tocca una sola funzione. Un percorso di importazione che scrive un rack e un numero di unità su una macchina è un secondo percorso di scrittura che di quell’indice non sa nulla, e allora un giorno una macchina risulta registrata in due rack con un sistema esterno che conferma che è corretto.

La specifica di questa parte dice che una collocazione locale o un’assegnazione attiva non devono mai essere spazzate via da un’importazione. Ci sono due modi per renderlo vero. Uno è scrivere l’importazione in modo che lasci stare le assegnazioni. L’altro è rendere impossibile all’importazione scrivere un’assegnazione, ed è quello che abbiamo preso: non c’è alcun campo che ci porti.

A farlo rispettare è una guardia sull’albero sintattico astratto anziché un caso di test. Legge il sorgente del modulo di importazione e pretende che le quattro tabelle protette, le assegnazioni, gli slot, le associazioni di servizio e le etichette, compaiano soltanto dentro un select. Un insert, un update o un delete su una qualsiasi di esse è rosso anche se nessun percorso di codice ci arriva mai, perché la garanzia deve valere per il codice che ancora non esiste. Il walker fallisce ad alta voce su una forma che non riconosce, che è una lezione imparata a caro prezzo in una guardia precedente che saltava in silenzio ciò che non riusciva ad analizzare.

I rifiuti sono elencati per nome nell’anteprima. L’omissione silenziosa è la versione pericolosa qui: qualcuno collega il proprio NetBox, legge «142 macchine aggiornate» e dà per scontato che sia arrivata anche la disposizione dei suoi rack.

Una cancellazione esterna è un tombstone

Un oggetto collegato che l’altra parte smette di menzionare diventa un tombstone con un’analisi d’impatto, non una cancellazione.

Non è soltanto una cortesia. Un elenco che torna corto per un errore di filtro, per una modifica dei permessi o per una pagina recuperata a metà svuoterebbe altrimenti l’inventario di un cliente. Il tombstone mette l’oggetto davanti a una persona, insieme a ciò che ne dipende: un oggetto con un’assegnazione attiva non si può rimuovere affatto, e dopo che l’assegnazione è stata rilasciata l’esito è una dismissione anziché una cancellazione.

E se si sa che il recupero è troncato, non succede assolutamente nulla. Non viene proposto alcun tombstone per niente. Quello che non si è visto non si può concludere che manchi. È una condizione di due righe ed è la differenza fra un connettore e un incidente.

Che cosa metteremmo per iscritto

1. 01Decidere la titolarità per colonna, non per oggetto, e far venire l’elenco delle colonne dallo schema perché una nuova non si possa dimenticare.
2. 02Memorizzare la motivazione insieme alla decisione. Un campo che non viene importato ha bisogno di una frase, altrimenti qualcuno lo importerà più avanti.
3. 03Rendere impossibile l’importazione pericolosa anziché prudente. Nessun campo che ci porti, più una guardia che legge il sorgente.
4. 04Nominare nell’anteprima ciò che si rifiuta, perché un numero di oggetti aggiornati si legge come completezza.
5. 05Trattare l’assenza come una domanda, mai come una cancellazione, e trattare un recupero troncato come nessuna informazione.

Sul nostro stato: questo sta dietro un flag di rollout disattivato per impostazione predefinita con sopra un’impostazione per organizzazione, quindi non è qualcosa da acquistare oggi, e non è mai stato eseguito contro un NetBox reale. Quanto detto sopra su come NetBox modella potenza, stato e ruoli viene dalla sua documentazione e dalla forma della sua interfaccia, non da una sua istanza di produzione. Tutto quanto sopra è stato misurato contro uno stub che riproduce il comportamento di paginazione, l’intestazione di versione e gli oggetti annidati dell’interfaccia reale, fissato alla versione di API che il codice di produzione invia. Lo stub offre davvero un rack, una posizione e un lato nei suoi payload di device, e vengono scritte zero assegnazioni: il rifiuto è misurato anziché supposto. La domanda collegata del perché un sistema esterno che riporta successo non sia di per sé un risultato sta in perché un 200 di Proxmox non è un esito.

Dal lavoro sul datacenter di Provibr. Il confine dell’occupazione da cui questa importazione viene tenuta lontana è descritto in l’unico limite reale all’occupazione di un rack, e le etichette i cui codici devono restare stabili in un’etichetta che sopravvive al cambio di hostname.