xinionos/docs/decisions/ADR-0005-geraeteschicht-aller-verkaufsvarianten.md

ADR-0005 — XinionOS ist die Geräteschicht aller Verkaufsvarianten; GAIA Lite wird Nutzlast

Stand: Angenommen, 21.08.2026 · Entscheidet: CIO Thomas Reitz Berührt: Projekt OLYMPUS — dessen Schichtenmodell führt GAIA Lite als Layer 2 der Verkaufsvariante. Diese Rolle geht auf XinionOS über.

---

Worum es geht

Zwei Vorhaben im Haus liefern ein Gerät an einen Kunden aus, und beide haben sich unabhängig voneinander dieselbe Schicht gebaut.

OLYMPUS beschreibt seine Verkaufsvariante als ISO auf Kundenhardware: GAIA Lite als Unterbau, k3s mit CORE- und WRK-Rollen, Bootstrapping über eine Deployment-Weboberfläche, Single-Tenant. XinionOS beschreibt genau dasselbe: ein Abbild, das installiert wird, sich selbst prüft, sich aktualisieren lässt und im Fehlerfall zurückspringt — mit Konsolenmenü, Einrichtungsassistent und Basisoberfläche.

Nebeneinander gelesen ist das zweimal dasselbe Gerüst: ISO-Auslieferung, Installation, Ersteinrichtung über eine Weboberfläche, Aktualisierung, Geräteverwaltung. Der Unterschied liegt nicht in der Aufgabe, sondern darin, dass zwei Vorhaben sie zu verschiedenen Zeitpunkten für sich gelöst haben.

Die Entscheidung

XinionOS ist die Geräteschicht jedes Xinion-Erzeugnisses, das beim Kunden als Gerät steht. GAIA Lite hört auf, ein Auslieferungsweg zu sein, und wird zu einer Nutzlast auf XinionOS.

Damit ersetzt XinionOS nicht OLYMPUS, sondern genau den Teil, den OLYMPUS nach unten weggeschnitten hatte, ohne dass es dafür einen Träger gab.

Aufgabe	Bisher	Künftig
ISO bauen und ausliefern	GAIA Lite	XinionOS
Installation am Blech	GAIA Lite	XinionOS (Stufe 0)
Ersteinrichtung über Weboberfläche	Deployment-WebUI	XinionOS (Stufe 2)
Notfallzugang ohne Netz	fehlte	XinionOS (Konsolenmenü, Stufe 1)
Fassungswechsel und Rücksprung	offen	XinionOS (A/B-Wurzel, Selbstprüflauf)
Verschlüsselung, sichere Löschung	offen	XinionOS (ADR-0003)
k3s, PostgreSQL, Storage, Secrets, Ingress, IdP — der Plattform-Vertrag	GAIA Lite	GAIA Lite, als Nutzlast
Shell, Auth, Mandantenfähigkeit, Registry, Gateway, Shared Services, Lizenzierung	OLYMPUS	OLYMPUS, unverändert
Die Anwendungen	INSIGHT, COSMOS, ORION-WebUI	unverändert

OLYMPUS und die Anwendungen merken davon nichts. Sie konsumieren Layer 2 weiterhin ausschließlich über den Plattform-Vertrag; welcher Träger ihn erfüllt, ist genau die Austauschbarkeit, die OLYMPUS selbst festgeschrieben hat.

Warum

Der Cyber Resilience Act rechnet in Erzeugnissen, nicht in Vorhaben. Zwei Basissysteme sind zwei Stücklisten, zwei Schwachstellenprozesse und zwei Versorgungszusagen über die Produktlebensdauer — für dieselbe Sache. Das ist die Begründung aus ADR-0001, jetzt angewandt auf einen konkreten zweiten Fall.

Der Rücksprung wird nur einmal richtig gebaut. Er wird ausschließlich in dem Moment geprüft, in dem ihn jemand braucht. Eine zweite handgebaute Umsetzung wäre eine zweite ungeprüfte — und die fällt erst beim Kunden auf.

Das Konsolenmenü fehlte auf der anderen Seite ganz. Eine Deployment-Weboberfläche setzt ein funktionierendes Netz und einen funktionierenden Webdienst voraus. Was passiert, wenn das Netz falsch konfiguriert ist, war nicht beantwortet. Die Notfalloberfläche muss den Ausfall dessen überleben, was sie verwaltet.

Und es ist keine neue Konstruktion, sondern das Einlösen einer vorhandenen. Der Nutzlast-Vertrag ist genau dafür geschnitten; die XinionOS-Seite führt die OLYMPUS-Appliance seit dem 20.08.2026 als eine von vier Nutzlasten. Diese Entscheidung macht aus einer Absicht eine Festlegung.

Was daraus folgt

• GAIA Lite erfüllt den Nutzlast-Vertrag — selbstpruefung, nutzlast.target, kennung, optional einrichten. Der Selbstprüflauf von GAIA Lite entscheidet über den Rücksprung mit: Ein k3s, das nicht hochkommt, ist ein misslungener Start und kein grünes Gerät.
• Ein ISO-Bauweg, ein Abnahmetest, ein Ersatzteil im Regal.
• Die Deployment-WebUI von GAIA Lite entfällt als eigener Baustein. Was von ihr fachlich gebraucht wird, gehört in den Einrichtungsassistenten von XinionOS.
• Zwei Registries und zwei Lizenzmechaniken bleiben bestehen — die von XinionONE für seine Module, die von OLYMPUS für seine Anwendungen. Sie sehen sich ähnlich und liegen trotzdem in verschiedenen Nutzlasten. Sie werden nicht zusammengelegt, solange nicht jemand nachweist, dass sie dasselbe tun.

Die Auflage, die daraus folgt: Container-Abbilder gehören in die Wurzel

Nachgetragen am 21.08.2026, nachdem die Frage gestellt wurde, ob GAIA Lite und das Grundmodul der Appliance dieselbe Schicht sind. Sie sind es nicht — aber die Frage hat eine Lücke in dieser Entscheidung aufgedeckt.

appliance/ADR-0005 hat für die Verpackung der Dienste festgehalten, was hier genauso gilt und oben fehlte: Was nicht in der Wurzel liegt, nimmt der Rücksprung nicht mit. Lägen die Dienste im Bestandsbereich, träfe nach einem Rücksprung eine alte Wurzel auf eine neue Anwendung.

Für GAIA Lite als Nutzlast heißt das konkret:

Was	Wohin	Warum
k3s selbst, alle Container-Abbilder, Helm-Bündel, Manifeste	Wurzel	Software. Wird mitgetauscht und kommt beim Rücksprung von selbst zurück
etcd beziehungsweise die Cluster-Datenbank, persistente Datenträger, Zustand der Anwendungen	Bestand	Zustand des Kunden. Überlebt den Fassungswechsel absichtlich

Damit gilt für GAIA Lite dieselbe Schemaregel wie für jede andere Nutzlast (ADR-0004 der Appliance): Eine Fassung darf den Zustand nur so ändern, dass die Vorgängerfassung noch damit arbeiten kann. Ein Rücksprung, der auf einen fortgeschriebenen Cluster-Zustand trifft, ist kein Rückweg, sondern ein zweiter Ausfall.

Und es ist eine Abbildgrößen-Frage. Nach ADR-0004 bleibt das Abbild klein, weil alles zweimal auf der Platte liegt — einmal je Wurzel. Ein vollständiger Satz Container-Abbilder für Plattform und Anwendungen ist kein kleiner Posten. Was GAIA Lite in die Wurzel legt, ist vor dem ersten Abbildbau zu beziffern, nicht danach.

Was ausdrücklich nicht entschieden ist

• Ob GAIA Full ebenfalls auf XinionOS läuft. Diese Entscheidung betrifft nur, was beim Kunden als Gerät steht. Im eigenen Rechenzentrum bleibt alles, wie es ist.
• Wann der Umbau geschieht. OLYMPUS ist Konzept, XinionOS ist Konzept — hier kollidieren zwei Pläne, kein Bestand. Das ist der günstigste Zeitpunkt, den es dafür je geben wird.
• Der Name. CORE bezeichnet bei OLYMPUS eine k3s-Rolle, bei XinionONE die Bezugsquelle, im Namensschema zusätzlich das Grundmodul. Drei Dinge, ein Wort — zu entscheiden, aber nicht hier.

---

Grundlage: Projekt OLYMPUS, Startseite vom 23.06.2026 (Schichtenmodell, Plattform-Vertrag, die zwei Ausprägungen) · XinionOS ADR-0001 bis ADR-0004 · nutzlast/VERTRAG.md · Nichts davon ist gebaut — diese Entscheidung ordnet Pläne, sie beschreibt keinen Zustand.