Wenn NetBox die Quelle der Wahrheit ist

Ein Kunde mit einem funktionierenden NetBox will kein zweites Inventar. Er will, dass seine Racks und seine Maschinen in der Plattform auftauchen, aus der heraus er arbeitet, und er will sie weiterhin an der Stelle pflegen, die sein Team schon kennt.

Das Wort, das man dafür üblicherweise benutzt, ist „Synchronisierung“, und das Wort ist das Problem. Synchronisierung setzt voraus, dass zwei Systeme zu einer Wahrheit zusammenlaufen. Was Sie tatsächlich haben, ist eine Frage je Feld, die im Voraus beantwortet und aufgeschrieben werden muss: Wer bestimmt über diese Spalte an diesem Objekt? Beantworten Sie sie einmal mit einem Achselzucken, und Sie haben ein System gebaut, das um drei Uhr nachts eine bewusste lokale Änderung überschreibt, oder eines, das eine Änderung stillschweigend übergeht, die der Kunde vor einer Stunde gemacht hat und für angekommen hält.

So haben wir sie beantwortet, einschließlich der Felder, bei denen die Antwort nein lautet.

Vier Werte, und sie sind keine Vertrauensstufen

Jede Spalte jedes verknüpften Objekts trägt einen von vier Hoheitswerten, und sie sagen vier verschiedene Dinge darüber, wer bestimmt, statt vier Stufen der Zuversicht.

Extern. Die andere Seite bestimmt. Das Feld ist hier nur lesbar, und ein Import überschreibt es ohne Rückfrage. Das ist kein Verlust an Kontrolle, es ist die Abmachung, die der Administrator beim Anbinden des Systems eingegangen ist.

Unsere. Wir bestimmen, und ein Import fasst es nicht an. Das ist der Zustand jedes Feldes eines Objekts, das überhaupt nicht verknüpft ist, und jedes Feldes, für das das externe System kein Gegenstück hat.

Manuell gesperrt. Die andere Seite hat sehr wohl einen Wert, und ein Administrator hat ihn hier bewusst und mit einer Begründung überschrieben. Ein Unterschied ist dann ein Konflikt, der sichtbar gemacht wird, nie eine stille Überschreibung. Das ist der einzige der vier Werte, der nicht als Voreinstellung entstehen kann: Jemand setzt ihn.

Abgeleitet. Niemand bestimmt. Es folgt aus etwas anderem: ob eine Maschine im Rack steht, ob sie an einen Dienst gebunden ist, ob sie bereit ist, die Kapazität eines Racks, die Buchführung der Zeile selbst. Diese sind strukturell nicht importierbar, und ein Test behauptet, dass sie in keiner Abbildung je auftauchen.

Der letzte verdient eine Anmerkung. Die Felder der Buchführung, wer eine Zeile angelegt hat und wann, sind abgeleitet und nicht unsere. Niemand wählt diese Werte, sie folgen aus der Handlung. Ein Importweg, der einen Anlagezeitpunkt schreiben darf, ist ein Importweg, der Geschichte umschreiben kann.

Die Hoheit hängt an der Verknüpfung und nicht am Objekt. Ein Objekt ohne Verknüpfung ist vollständig unseres, das Lösen der Verknüpfung ist also ein einzelnes Löschen und keine Wanderung von Zustand über jede Spalte hinweg.

Das Register gilt je Spalte, und die Spaltenliste kommt aus dem Schema

Jede Spalte der vier unterstützten Objekttypen, Standorte, Standortbereiche, Racks und Maschinen, hat einen Eintrag in einem Register. Auch die, die mit dem externen System nicht das Geringste zu tun haben.

Diese Vollständigkeit wird durchgesetzt und nicht bloß beabsichtigt. Ein Test leitet die Spaltenliste aus dem Datenbankschema ab und verlangt für jede eine Entscheidung. Eine neue Spalte, die in irgendeiner späteren Runde hinzukommt, ist deshalb ein roter Test statt einer stillen Lücke, und das ist dieselbe Konstruktion, die wir anderswo benutzen: Ein Test je Fall kann seiner Natur nach keinen fehlenden Fall finden.

Einige der Entscheidungen sind der interessante Teil.

Das Leistungsbudget eines Racks bleibt unseres. NetBox bildet Strom als Einspeisungen ab und nicht als eine einzelne Budgetzahl. Aus mehreren Einspeisungen eine Zahl abzuleiten wäre eine Kapazitätsaussage, die aus unvollständigen Daten zusammengesetzt ist, und genau das verbietet der Kapazitätsentwurf. Das Feld wird also nicht importiert, mit diesem Satz als Begründung daneben.

Der Prozesszustand einer Maschine bleibt unserer. NetBox mischt im Gerätestatus Lebenszyklus und Betrieb in einem Feld. Ein als ausgefallen markiertes Gerät würde bei einer naiven Abbildung eine Maschine in einen Wartungszustand schieben und sie aus dem verkäuflichen Bestand nehmen. Das sind zwei verschiedene Vokabulare, die sich zufällig einen Namen teilen.

Die Art einer Maschine bleibt unsere. Die Geräterolle in NetBox ist freier Text. Dort falsch zu raten erzeugt keinen kosmetischen Fehler, es ändert, was die Plattform Sie mit einer Maschine tun lässt.

Jede dieser Entscheidungen ist mit einer geschriebenen Begründung gespeichert, in derselben Struktur wie die Entscheidung. Eine Regel mit einer Begründung daran überlebt den nächsten Menschen; eine Regel ohne wird von jemandem gelockert, der annimmt, sie sei willkürlich gewesen.

Nur beim Anlegen, denn es liegen Aufkleber in einer Schachtel

Zwei Felder werden einmal importiert, beim Anlegen, und nie aktualisiert: der Code eines Standorts, eines Standortbereichs oder eines Racks und der Asset-Tag einer Maschine.

Der Grund ist physisch. Diese Werte sind auf Etiketten gedruckt, und die Etiketten liegen in einer Schachtel in einem Materialschrank. Ein Slug, der im nächsten Frühjahr in NetBox umbenannt wird, darf einen Scan nicht an die falsche Stelle schicken. Nur beim Anlegen ist kein dritter Hoheitswert, es ist eine Eigenschaft des Imports: beim Hinzufügen übernehmen, danach in Ruhe lassen.

Dieselben Felder sind es, über die ein noch nicht verknüpftes Objekt zugeordnet wird, wenn die Verbindung zum ersten Mal hergestellt wird: der Code für die anderen drei, der Asset-Tag für Maschinen. Bewusst nicht der Name, denn ein Code ist stabil und ohne Rücksicht auf Groß- und Kleinschreibung eindeutig, und ein Name ist keines von beidem.

Platzierung wird nie importiert, und es gibt kein Feld, das dorthin führt

NetBox kennt für jedes Gerät sein Rack, seine Position und seine Seite. Diese drei werden abgelehnt.

Nicht übergangen. Abgelehnt, namentlich, mit einem Grundcode, und in der Vorschau gezeigt.

Die Begründung folgt unmittelbar aus dem Belegungsentwurf: Die einzige echte Grenze der Rackbelegung ist ein partieller eindeutiger Index auf der Slot-Tabelle, und dieser Index wird immer nur von einer einzigen Funktion berührt. Ein Importweg, der ein Rack und eine Unit-Nummer auf eine Maschine schreibt, ist ein zweiter Schreibweg, der von diesem Index nichts weiß, und dann ist eines Tages eine Maschine in zwei Racks erfasst, mit einem externen System, das bestätigt, dass das so richtig ist.

Die Spezifikation für diesen Abschnitt sagt, dass eine lokale Platzierung oder eine aktive Buchung durch einen Import niemals ausgelöscht werden darf. Es gibt zwei Wege, das wahr zu machen. Der eine ist, den Import so zu schreiben, dass er Buchungen in Ruhe lässt. Der andere ist, es dem Import unmöglich zu machen, überhaupt eine Buchung zu schreiben, und diesen haben wir genommen: Es gibt kein Feld, das dorthin führt.

Durchgesetzt wird das von einem Wächter auf dem abstrakten Syntaxbaum und nicht von einem Testfall. Er liest den Quelltext des Importmoduls und verlangt, dass die vier geschützten Tabellen, die Buchungen, die Slots, die Dienstbindungen und die Etiketten, nur innerhalb eines select auftauchen. Ein insert, ein update oder ein delete auf einer von ihnen ist rot, selbst wenn kein Codepfad sie je erreicht, denn die Garantie muss für Code gelten, den es noch nicht gibt. Der Walker schlägt laut fehl bei einer Form, die er nicht kennt, und das ist eine teuer gelernte Lektion aus einem früheren Wächter, der still übersprang, was er nicht lesen konnte.

Ablehnungen werden in der Vorschau namentlich aufgeführt. Das stille Weglassen ist hier die gefährliche Fassung: Jemand bindet sein NetBox an, liest „142 Maschinen aktualisiert“ und nimmt an, dass sein Racklayout mitgekommen ist.

Ein externes Löschen ist ein Tombstone

Ein verknüpftes Objekt, das die andere Seite nicht mehr erwähnt, wird zu einem Tombstone mit einer Auswirkungsprüfung und nicht zu einer Löschung.

Das ist nicht bloß höflich. Eine Liste, die wegen eines Filterfehlers, einer geänderten Berechtigung oder einer halb geholten Seite zu kurz zurückkommt, würde sonst das Inventar eines Kunden leerräumen. Der Tombstone stellt das Objekt einem Menschen vor Augen, zusammen mit dem, was davon abhängt: Ein Objekt mit einer aktiven Buchung lässt sich überhaupt nicht entfernen, und nachdem die Buchung freigegeben ist, ist das Ergebnis eine Ausmusterung und keine Löschung.

Und wenn bekannt ist, dass der Abruf abgeschnitten war, passiert gar nichts. Es werden für nichts Tombstones vorgeschlagen. Was Sie nicht gesehen haben, davon können Sie nicht schließen, dass es fehlt. Das ist eine Bedingung von zwei Zeilen, und sie ist der Unterschied zwischen einem Konnektor und einem Zwischenfall.

Was wir aufschreiben würden

1. 01Entscheiden Sie die Hoheit je Spalte, nicht je Objekt, und lassen Sie die Spaltenliste aus dem Schema kommen, damit eine neue nicht vergessen werden kann.
2. 02Speichern Sie die Begründung zusammen mit der Entscheidung. Ein Feld, das nicht importiert wird, braucht einen Satz, sonst importiert es jemand später.
3. 03Machen Sie den gefährlichen Import unmöglich statt sorgfältig. Kein Feld dorthin, dazu ein Wächter, der den Quelltext liest.
4. 04Benennen Sie in der Vorschau, was Sie ablehnen, denn eine Anzahl aktualisierter Objekte liest sich als Vollständigkeit.
5. 05Behandeln Sie Abwesenheit als Frage, nie als Löschung, und einen abgeschnittenen Abruf als überhaupt keine Information.

Zu unserem eigenen Stand: Das liegt hinter einem Rollout-Schalter, der standardmäßig aus ist, mit einer Einstellung je Organisation darüber, es ist also heute nichts zu kaufen, und es ist nicht gegen ein echtes NetBox gelaufen. Was oben darüber gesagt wird, wie NetBox Strom, Status und Rollen abbildet, stammt aus seiner Dokumentation und aus der Form seiner Schnittstelle und nicht aus einer Produktionsinstanz davon. Alles oben Beschriebene wurde gegen einen Stub gemessen, der das Blätterverhalten, den Versions-Header und die verschachtelten Objekte der echten Schnittstelle nachbildet, festgenagelt auf die API-Version, die der Produktionscode sendet. Der Stub bietet in seinen Geräte-Nutzdaten tatsächlich ein Rack, eine Position und eine Seite an, und es werden null Buchungen geschrieben: Die Ablehnung ist gemessen und nicht angenommen. Die verwandte Frage, warum ein externes System, das Erfolg meldet, für sich noch kein Ergebnis ist, steht in warum eine 200 von Proxmox kein Ergebnis ist.

Aus der Rechenzentrumsarbeit bei Provibr. Die Belegungsgrenze, von der dieser Import ferngehalten wird, ist beschrieben in die einzige echte Grenze der Rackbelegung, und die Etiketten, deren Codes stabil bleiben müssen, in ein Etikett, das einen Hostnamenwechsel überlebt.