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 <noreply@anthropic.com>
This commit is contained in:
parent
6b0ae580a5
commit
e61353b87d
1 changed files with 96 additions and 0 deletions
|
|
@ -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.*
|
||||
Loading…
Add table
Reference in a new issue