Als NetBox de bron van waarheid is

Een klant met een werkende NetBox wil geen tweede inventaris. Hij wil dat zijn racks en zijn machines verschijnen in het platform waaruit hij werkt, en hij wil ze blijven bewerken op de plek die zijn team al kent.

Het woord dat daar meestal aan hangt is "synchronisatie", en dat woord is het probleem. Synchronisatie suggereert twee systemen die naar één waarheid toe bewegen. Wat je werkelijk hebt is een vraag per veld die vooraf beantwoord en opgeschreven moet worden: wie beslist er voor deze kolom, op dit object? Beantwoord je hem één keer met een schouderophalen, dan heb je een systeem gebouwd dat om drie uur 's nachts een bewuste lokale wijziging overschrijft, of een systeem dat stilzwijgend een wijziging negeert die de klant een uur geleden maakte en waarvan hij denkt dat die is aangekomen.

Zo hebben wij hem beantwoord, inclusief de velden waar het antwoord nee is.

Vier waarden, en het zijn geen gradaties van vertrouwen

Elke kolom van elk gekoppeld object draagt een van vier waarden voor eigenaarschap, en die zeggen vier verschillende dingen over wie beslist en niet vier niveaus van zekerheid.

Extern. De andere kant beslist. Het veld is hier alleen-lezen en een import overschrijft het zonder te vragen. Dat is geen verlies van controle, het is de afspraak die de beheerder aanging toen hij het systeem koppelde.

Van ons. Wij beslissen, en een import raakt het niet aan. Dit is de toestand van elk veld van een object dat helemaal niet gekoppeld is, en van elk veld waar het externe systeem geen tegenhanger voor heeft.

Handmatig vergrendeld. De andere kant heeft wel een waarde, en een beheerder heeft die hier bewust overschreven, met een reden. Een verschil is dan een conflict dat aan de oppervlakte komt, nooit een stille overschrijving. Dit is de enige van de vier die niet als standaard kan ontstaan: iemand zet hem.

Afgeleid. Niemand beslist. Het volgt uit iets anders: of een machine in een rack staat, of hij aan een dienst gebonden is, of hij klaar is, de capaciteit van een rack, de boekhouding van de regel zelf. Die zijn structureel niet importeerbaar, en een test stelt vast dat ze in geen enkele veldtoewijzing voorkomen.

Die laatste verdient een aantekening. De boekhoudvelden, wie een regel aangemaakt heeft en wanneer, zijn afgeleid en niet van ons. Niemand kiest die waarden, ze volgen uit de handeling. Een importpad dat een aanmaaktijdstip mag schrijven is een importpad dat geschiedenis kan herschrijven.

Het eigenaarschap hangt aan de koppeling en niet aan het object. Een object zonder koppeling is volledig van ons, wat betekent dat ontkoppelen één verwijdering is en geen verhuizing van toestand over elke kolom.

Het register is per kolom, en de kolomlijst komt uit het schema

Elke kolom van de vier ondersteunde objectsoorten, sites, locaties, racks en machines, heeft een regel in een register. Inclusief de kolommen die helemaal niets met het externe systeem te maken hebben.

Die volledigheid wordt afgedwongen en niet slechts bedoeld. Een test leidt de kolomlijst uit het databaseschema af en eist voor elke kolom een beslissing. Een nieuwe kolom die in een latere ronde wordt toegevoegd is daarmee een rode test in plaats van een stil gat, en dat is dezelfde constructie die we elders gebruiken: een test per geval kan van nature geen geval vinden dat ontbreekt.

Enkele van de beslissingen zijn het interessante deel.

Het vermogensbudget van een rack blijft van ons. NetBox modelleert vermogen als voedingen, niet als één budgetgetal. Uit meerdere voedingen één getal afleiden zou een capaciteitsbewering zijn die uit onvolledige gegevens is samengesteld, en dat is precies wat het capaciteitsontwerp verbiedt. Het veld wordt dus niet geïmporteerd, met die zin ernaast vastgelegd als de reden.

De processtatus van een machine blijft van ons. De apparaatstatus van NetBox mengt levenscyclus en bedrijfsvoering in één veld. Een apparaat dat als defect gemarkeerd staat zou bij een naïeve toewijzing een machine in een onderhoudstoestand duwen en uit de verkoopbare voorraad halen. Dat zijn twee verschillende woordenschatten die toevallig een naam delen.

De soort van een machine blijft van ons. De apparaatrol van NetBox is vrije tekst. Daar verkeerd gokken levert geen cosmetische fout op, het verandert wat het platform je met een machine laat doen.

Elk daarvan wordt met een geschreven reden opgeslagen, in dezelfde structuur als de beslissing. Een regel met een reden erbij overleeft de volgende persoon; een regel zonder reden wordt versoepeld door iemand die aanneemt dat hij willekeurig was.

Alleen bij aanmaken, want er liggen stickers in een doos

Twee velden worden één keer geïmporteerd, bij het aanmaken, en daarna nooit bijgewerkt: de code van een site, locatie of rack, en de assettag van een machine.

De reden is fysiek. Die waarden staan op etiketten gedrukt, en de etiketten liggen in een doos in een voorraadkast. Een slug die volgend voorjaar in NetBox hernoemd wordt mag geen scan naar de verkeerde plek sturen. Alleen bij aanmaken is geen derde waarde voor eigenaarschap, het is een eigenschap van de import: neem hem mee bij het toevoegen, laat hem daarna met rust.

Dezelfde velden zijn waarop een ongekoppeld object wordt gematcht wanneer de verbinding voor het eerst gelegd wordt: de code voor de andere drie, de assettag voor machines. Met opzet niet de naam, want een code is stabiel en uniek ongeacht hoofdlettergebruik, en een naam is geen van beide.

Plaatsing wordt nooit geïmporteerd, en er is geen veld dat daarheen leidt

NetBox kent voor elk apparaat zijn rack, zijn positie en zijn zijde. Die drie worden geweigerd.

Niet genegeerd. Geweigerd, bij naam, met een redencode, en getoond in de voorvertoning.

De redenering volgt rechtstreeks uit het bezettingsontwerp: de enige echte grens op rackbezetting is een partiële unieke index op de slottabel, en die index wordt maar door één functie ooit aangeraakt. Een importpad dat een rack en een unitnummer op een machine schrijft is een tweede schrijfweg die van die index niets weet, en dan staat er op een dag een machine in twee racks vastgelegd met een extern systeem dat bevestigt dat dat klopt.

De specificatie voor dit deel zegt dat een lokale plaatsing of actieve claim nooit door een import mag worden weggevaagd. Er zijn twee manieren om dat waar te maken. De ene is de import zo schrijven dat hij claims met rust laat. De andere is het onmogelijk maken dat de import überhaupt een claim schrijft, en dat is de weg die wij gekozen hebben: er is geen veld dat daarheen leidt.

Dat afdwingen is een AST-bewaking en geen testgeval. Hij leest de bron van de importmodule en eist dat de vier beschermde tabellen, de claims, de slots, de dienstkoppelingen en de etiketten, alleen binnen een select voorkomen. Een insert, een update of een delete op een ervan is rood, ook als geen enkel codepad hem ooit bereikt, want de garantie moet gelden voor code die nog niet bestaat. De walker faalt luidruchtig op een vorm die hij niet herkent, wat een les is die duur geleerd is bij een eerdere bewaking die stil oversloeg wat hij niet kon ontleden.

Weigeringen worden bij naam in de voorvertoning genoemd. Stil weglaten is hier de gevaarlijke variant: iemand koppelt zijn NetBox, leest "142 machines bijgewerkt", en gaat ervan uit dat zijn rackindeling meegekomen is.

Een externe verwijdering is een tombstone

Een gekoppeld object dat de andere kant niet meer noemt wordt een tombstone met een impactbeoordeling, en geen verwijdering.

Dat is niet slechts beleefd. Een lijst die te kort terugkomt door een filterfout, een rechtenwijziging of een half opgehaalde pagina zou anders de inventaris van een klant leegruimen. De tombstone legt het object aan een mens voor, samen met wat ervan afhangt: een object met een actieve claim kan helemaal niet verwijderd worden, en nadat de claim vrijgegeven is is de uitkomst een buitengebruikstelling en geen verwijdering.

En is bekend dat het ophalen afgekapt is, dan gebeurt er helemaal niets. Er worden voor niets tombstones voorgesteld. Wat je niet gezien hebt, kun je niet als ontbrekend beschouwen. Dat is een voorwaarde van twee regels en het is het verschil tussen een koppeling en een incident.

Wat we zouden opschrijven

1. 01Beslis eigenaarschap per kolom, niet per object, en laat de kolomlijst uit het schema komen zodat een nieuwe kolom niet vergeten kan worden.
2. 02Bewaar de reden bij de beslissing. Een veld dat niet geïmporteerd wordt heeft een zin nodig, of iemand importeert het later alsnog.
3. 03Maak de gevaarlijke import onmogelijk in plaats van zorgvuldig. Geen veld ernaartoe, plus een bewaking die de bron leest.
4. 04Benoem in de voorvertoning wat je weigert, want een aantal bijgewerkte objecten leest als volledigheid.
5. 05Behandel afwezigheid als een vraag, nooit als een verwijdering, en behandel een afgekapt ophalen als helemaal geen informatie.

Over onze eigen stand: dit zit achter een uitrolvlag die standaard uit staat met daarbovenop een instelling per organisatie, dus het is niets om vandaag te kopen, en het heeft niet tegen een echte NetBox gedraaid. Wat hierboven staat over hoe NetBox vermogen, status en rollen modelleert komt uit zijn documentatie en uit de vorm van zijn interface, niet uit een productie-instantie ervan. Alles hierboven is gemeten tegen een stub die het pagineergedrag, de versiekop en de geneste objecten van de echte interface nabootst, vastgezet op de API-versie die de productiecode stuurt. De stub biedt werkelijk een rack, een positie en een zijde in zijn apparaatgegevens aan, en er worden nul claims geschreven: de weigering is gemeten en niet aangenomen. De verwante vraag waarom een extern systeem dat succes meldt op zichzelf geen resultaat is staat in waarom een Proxmox-200 geen uitkomst is.

Uit het datacenterwerk aan Provibr. De bezettingsgrens waar deze import bij weggehouden wordt staat beschreven in de enige echte grens op rackbezetting, en de etiketten waarvan de codes stabiel moeten blijven in een etiket dat een hostnaamwijziging overleeft.