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.
125 lines
3.8 KiB
Markdown
125 lines
3.8 KiB
Markdown
# Feature- und Blueprint-Modell
|
|
|
|
**Status:** Entwurf
|
|
**Datum:** 17.07.2026
|
|
|
|
## Zweck dieses Dokuments
|
|
|
|
Dieses Dokument beschreibt, wie die Merkmale eines Workspace für ein konkretes Backend technisch umgesetzt werden.
|
|
|
|
Es ergänzt das Workspace-Modell (`02-workspace-model.md`) und das Backend-Modell um den bisher fehlenden Übersetzungsmechanismus und präzisiert den Begriff „Blueprint" aus dem Glossar.
|
|
|
|
---
|
|
|
|
## Motivation
|
|
|
|
Ein Workspace beschreibt einen Einsatzzweck, nicht seine technische Umsetzung.
|
|
|
|
Ein Backend beschreibt eine Distribution, nicht die einzelnen fachlichen Eigenschaften eines Workspace.
|
|
|
|
Zwischen beiden fehlt ein Bindeglied: die Frage, wie ein einzelnes Merkmal eines Workspace auf einem bestimmten Backend konkret realisiert wird.
|
|
|
|
Dieses Bindeglied ist der Blueprint.
|
|
|
|
---
|
|
|
|
## Definition
|
|
|
|
### Merkmal
|
|
|
|
Ein Merkmal ist eine einzelne fachliche Eigenschaft eines Workspace.
|
|
|
|
Ein Merkmal ist distributionsunabhängig benannt.
|
|
|
|
Beispiele:
|
|
|
|
- browser-brave
|
|
- office-onlyoffice
|
|
- guest-session-ephemeral
|
|
- appstore
|
|
|
|
Ein Workspace besteht aus einer Menge von Merkmalen.
|
|
|
|
### Blueprint
|
|
|
|
Ein Blueprint beschreibt die technische Umsetzung genau eines Merkmals für genau ein Backend.
|
|
|
|
Ein Blueprint ist im Regelfall eine Ansible-Rolle bzw. -Aufgabe.
|
|
|
|
Für ein Merkmal existiert je unterstütztem Backend höchstens ein Blueprint.
|
|
|
|
Beispiel:
|
|
|
|
| Merkmal | Backend | Blueprint |
|
|
|---|---|---|
|
|
| browser-brave | fedora | Ansible-Rolle „brave-fedora" (dnf, Brave-Repository) |
|
|
| browser-brave | mint | Ansible-Rolle „brave-mint" (apt, Brave-Repository) |
|
|
| guest-session-ephemeral | fedora | Ansible-Rolle „guest-session" (tmpfs-Home, PAM) |
|
|
| guest-session-ephemeral | mint | Ansible-Rolle „guest-session" (tmpfs-Home, PAM) |
|
|
|
|
Ein Blueprint kann von mehreren Backends wiederverwendet werden, wenn die Umsetzung identisch ist.
|
|
|
|
### Runtime Blueprint
|
|
|
|
Das Runtime Blueprint einer konkreten Installation entsteht, indem für jedes Merkmal des gewählten Workspace der zum gewählten Backend passende Blueprint aufgelöst wird.
|
|
|
|
Die Sammlung aller aufgelösten Blueprints wird nach dem ersten Start über den bestehenden Ansible-Pull-Mechanismus angewendet.
|
|
|
|
---
|
|
|
|
## Abgrenzung zu installationszeitlichen Vorgaben
|
|
|
|
Partitionierung, Festplattenverschlüsselung, Secure-Boot- und TPM-Bindung sowie weitere zur Installationszeit unveränderliche Eigenschaften sind kein Bestandteil eines Blueprints.
|
|
|
|
Sie werden als direkte Vorgabe der gewählten Bereitstellungsvorlage an `backend_generate_config()` übergeben und fließen unmittelbar in die native Installationskonfiguration ein (siehe `06-backend-api.md`, `08-provisioning-api.md`).
|
|
|
|
Blueprints setzen ausschließlich userspace-seitige Merkmale um, die nach der Installation angewendet werden können, ohne die Partitionierung oder die native Installationskonfiguration zu verändern.
|
|
|
|
---
|
|
|
|
## Erweiterbarkeit
|
|
|
|
Neue Merkmale erfordern Blueprints für jedes bereits unterstützte Backend.
|
|
|
|
Neue Backends erfordern Blueprints für jedes bereits bestehende Merkmal.
|
|
|
|
Workspace- und Merkmal-Definitionen bleiben davon unberührt.
|
|
|
|
---
|
|
|
|
## Beispiel
|
|
|
|
### Workspace: Schulcomputer
|
|
|
|
Merkmale:
|
|
|
|
- guest-session-ephemeral
|
|
- browser-brave
|
|
- office-onlyoffice
|
|
|
|
### Workspace: Entwickler
|
|
|
|
Merkmale:
|
|
|
|
- Programmiersprachen
|
|
- Virtualisierung
|
|
- Editoren
|
|
- Entwicklungsumgebungen
|
|
|
|
### Unterstützte Backends
|
|
|
|
- Fedora
|
|
- Linux Mint
|
|
|
|
---
|
|
|
|
## Zusammenfassung
|
|
|
|
Ein Workspace besteht aus Merkmalen.
|
|
|
|
Ein Blueprint setzt genau ein Merkmal für genau ein Backend um, in der Regel als Ansible-Rolle.
|
|
|
|
Das Runtime Blueprint einer konkreten Installation entsteht aus der Auflösung aller Merkmale des gewählten Workspace gegen das gewählte Backend.
|
|
|
|
Installationszeitliche Vorgaben wie Partitionierung und Verschlüsselung bleiben ein direkter Kanal der Bereitstellungsvorlage und sind kein Bestandteil eines Blueprints.
|