From e61353b87dd6c2a0afdf371e0df4a23bbacf5798 Mon Sep 17 00:00:00 2001 From: Thomas Reitz Date: Fri, 21 Aug 2026 17:25:09 +0200 Subject: [PATCH] ADR-0005: XinionOS traegt die Geraeteschicht aller Verkaufsvarianten OLYMPUS und XinionOS hatten sich unabhaengig voneinander dieselbe Schicht gebaut: ISO-Auslieferung, Installation, Ersteinrichtung, Aktualisierung. GAIA Lite gibt diese Rolle ab und wird eine Nutzlast auf XinionOS; der Plattform-Vertrag darueber bleibt unveraendert, OLYMPUS und die Anwendungen merken nichts davon. Begruendung: ein CRA-Dossier statt zwei, ein Ruecksprung statt zweier handgebauter, und ein Notfallzugang, den die andere Seite gar nicht hatte. Co-Authored-By: Claude Opus 5 --- ...-geraeteschicht-aller-verkaufsvarianten.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 docs/decisions/ADR-0005-geraeteschicht-aller-verkaufsvarianten.md diff --git a/docs/decisions/ADR-0005-geraeteschicht-aller-verkaufsvarianten.md b/docs/decisions/ADR-0005-geraeteschicht-aller-verkaufsvarianten.md new file mode 100644 index 0000000..921df7d --- /dev/null +++ b/docs/decisions/ADR-0005-geraeteschicht-aller-verkaufsvarianten.md @@ -0,0 +1,96 @@ +# 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. + +## 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.*