Thomas Stallinger
8ece25f954
Introduces the Merkmal-Backend-Blueprint realization model: a Merkmal describes one distribution-independent workspace feature, a Blueprint realizes exactly one Merkmal for exactly one backend (usually an Ansible role applied post-first-boot via ansible-pull), and a Bereitstellungsvorlage bundles workspace + backend + org-specific installation directives (partitioning, encryption, secure boot). Replaces the old flat profile model (profiles/profile.json/ distribution+version) throughout the provisioning API, data model, interactive provisioning flow, and device enrollment docs with templates/Bereitstellungsvorlage terminology. Moves 02-workspace-model.md and 04-backend-model.md into architecture/, archives the superseded flat organization-model.md.
2.3 KiB
ADR-0002: Blueprint als Merkmal-Backend-Realisierung über Ansible
Status: Beschlossen Datum: 17.07.2026
Kontext
Der Begriff „Blueprint" war im Glossar bisher nur grob als „technische Beschreibung eines Workspace" definiert.
Mit wachsender Anzahl an Workspaces (zum Beispiel Schulcomputer, Entwickler) und Backends (Fedora, Linux Mint) musste geklärt werden, wie einzelne fachliche Merkmale eines Workspace unabhängig von der gewählten Distribution wiederverwendbar umgesetzt werden können, ohne dass jede Kombination aus Workspace und Backend eigenständig gepflegt werden muss.
Zusätzlich musste geklärt werden, ob diese Umsetzung zur Installationszeit (nativer Installer, Kickstart/Autoinstall) oder nach dem ersten Start (Ansible) erfolgen soll.
Entscheidung
Ein Blueprint beschreibt die technische Umsetzung genau eines Merkmals für genau ein Backend.
Ein Blueprint ist im Regelfall eine Ansible-Rolle beziehungsweise -Aufgabe und wird nach dem ersten Start über den bestehenden Ansible-Pull-Mechanismus angewendet.
Der native Installer bleibt dadurch unabhängig von Workspace-Merkmalen. Er stellt lediglich das Basissystem sowie die Voraussetzungen für den Ansible-Pull-Mechanismus bereit (Netzwerk, Registrierung, Ansible-Repository).
Eigenschaften, die ausschließlich zur Installationszeit festgelegt werden können – insbesondere Partitionierung, Festplattenverschlüsselung sowie Secure-Boot- und TPM-Bindung – sind kein Bestandteil eines Blueprints. Sie werden als direkte Vorgabe der gewählten Bereitstellungsvorlage an backend_generate_config() übergeben.
Konsequenzen
Für jedes Merkmal wird je unterstütztem Backend ein eigener Blueprint gepflegt.
Neue Merkmale erfordern Blueprints für alle bestehenden Backends. Neue Backends erfordern Blueprints für alle bestehenden Merkmale. Workspace-Definitionen selbst bleiben davon unberührt.
Der native Installer benötigt keine Kenntnis einzelner Workspace-Merkmale.
Workspace-Merkmale, die eine Änderung der Partitionierung oder andere installationszeitliche Eingriffe erfordern würden, sind mit diesem Modell nicht darstellbar und müssen stattdessen als Vorgabe der Bereitstellungsvorlage modelliert werden.
Der Glossar-Eintrag „Blueprint" wird entsprechend präzisiert.
Details zum Merkmal- und Blueprint-Modell: architecture/12-feature-blueprint-model.md.