Hier ist eine detaillierte Aufschlüsselung, welche Funktionen unser STACKIT Provider-Plugin (theoretisch) abdeckt, nachdem es erfolgreich installiert und die `.endpoint`-Datei hochgeladen wurde.

**Voraussetzung:** Alle `Stackit...`-Wrapper-Klassen (z.B. `StackitInstance`, `StackitVolume`) in der `provider.py` wurden korrekt an die JSON-Antworten der STACKIT API angepasst.

---

## ✅ Teil 1: Basis-Funktionen (implementiert)

Diese Funktionen bilden das Fundament. Coriolis kann Ihre STACKIT-Umgebung jetzt "sehen" und als Quelle (Source) oder Ziel (Destination) für Migrations-Jobs auswählen.

### 1. Authentifizierung & Konnektivität
* **Status:** **Implementiert**
* **Funktion:** Coriolis kann die `.endpoint`-Datei lesen, sich über OAuth 2.0 bei der STACKIT IAM API authentifizieren und Bearer Tokens abrufen.
* **Test:** Die `authenticate()`-Methode testet erfolgreich die Verbindung zur **IaaS API** (`/flavors`) UND zur **Object Storage API** (`/buckets`). Der Endpoint wird in der UI als "Valid" angezeigt.

### 2. Inventarisierung (Ressourcen-Erkennung)
* **Status:** **Implementiert**
* **Funktion:** Coriolis kann die Listen-Funktionen aufrufen, um alle relevanten Ressourcen in Ihrem STACKIT-Projekt zu sehen.
* **Abgedeckte Methoden:**
    * `list_instances()`: Sie sehen alle Ihre VMs inklusive zugehöriger Labels (STACKIT "labels").
    * `list_volumes()`: Sie sehen alle Ihre Volumes inklusive Labels.
    * `list_snapshots()`: Sie sehen alle Volume-Snapshots; vererbte Labels werden ausgewiesen.
    * `list_networks()`: Sie sehen Ihre Netzwerke inklusive Labels.
    * `list_subnets()`: Zeigt "Pseudo-Subnetze", die aus den Netzwerk-CIDRs abgeleitet werden.
    * `list_images()`: Sie sehen alle verfügbaren OS-Images.
    * `list_flavors()`: Sie sehen alle verfügbaren VM-Größen.
* **Nutzen:** Unverzichtbar, um im Migrations-Assistenten Quell-VMs auszuwählen oder Ziel-Netzwerke/Flavors festzulegen. Die Labels erlauben jetzt detailliertes Tagging für UI-Filtern und Projekt-Metadaten.

### 3. Basis-Lebenszyklus-Management (VMs)
* **Status:** **Implementiert**
* **Funktion:** Grundlegende Steuerung von VMs.
* **Abgedeckte Methoden:**
    * `power_on_instance()`
    * `power_off_instance()`
    * `get_instance_status()`
* **Nutzen:** Coriolis kann VMs vor einer Snapshot-Erstellung sicher herunterfahren.

### 4. Basis-Storage-Management (Volumes & Snapshots)
* **Status:** **Implementiert**
* **Funktion:** Erstellen und Löschen von Storage-Ressourcen.
* **Abgedeckte Methoden:**
    * `create_snapshot()`: **Sehr wichtig.** Dies ist der erste Schritt einer jeden Migration von STACKIT weg.
    * `delete_snapshot()`: Wichtig für das Aufräumen.
    * `create_volume()`: Erstellt ein neues, leeres Volume. Wird als Basis für den Daten-Import benötigt.
    * `delete_volume()`: Wichtig für das Aufräumen.
    * `attach_volume()` / `detach_volume()`: Wichtig, um Volumes an temporäre Worker-VMs anzuhängen.

### 5. Basis-Object-Storage-Management (Control Plane)
* **Status:** **Implementiert** (als interne Helfer-Methoden)
* **Funktion:** Vorbereitung des Datentransfers.
* **Abgedeckte Methoden:**
    * `_get_or_create_migration_bucket()`: Stellt sicher, dass ein S3-Bucket für die Migration existiert.
    * `_create_temp_s3_credentials()`: Erstellt S3 Access/Secret Keys für die Worker-VMs.
    * `_delete_temp_s3_credentials()`: Räumt die S3-Schlüssel nach dem Transfer wieder auf.
* **Nutzen:** Essenzielle Vorbereitung für die noch fehlenden Datentransfer-Funktionen.


## ✅ Teil 2: Erweiterte Migration-Funktionen (implementiert)

Diese Bausteine bilden den Kern des Worker-gestützten Migrations-Workflows, bei dem Coriolis temporäre VMs startet, um Daten physisch zu übertragen.

### 1. Datentransfer
* **Status:** **Implementiert (Worker-gestützt)**  
  `export_snapshot_to_url()` und `create_volume_from_url()` orchestrieren:
    * Region-aware IaaS-Aufrufe über den aktualisierten `StackitAPIClient`.
    * Bucket- und Access-Key-Lifecycle der Object-Storage-API.
    * Worker-VMs (Image/Flavor/Netzwerk frei konfigurierbar), die via cloud-init ein JSON-Job-Manifest erhalten **und** anschließend über die STACKIT **Run-Command v2** API Skripte zur eigentlichen Datenübertragung ausführen (Python/Boto3 + `lsblk`-basierte Device-Erkennung).
    * Polling für Volume- und Instanz-Status sowie optionales Verifizieren des hochgeladenen Objekts via S3 (`boto3`).
* **Voraussetzungen:** Neue `.endpoint`-Felder (Region, Worker-Image/-Flavor/-Netzwerk, Bucket-Name, optionaler S3-Endpoint, Run-Command-API-URL). Ohne korrektes Worker-Image oder aktivierten STACKIT-Agent lassen sich die Run-Command-Aufrufe nicht ausführen.
* **Cleanup/Output:** Worker-Instanzen und temporäre Clone-Volumes werden nach Abschluss aufgeräumt (`worker_auto_cleanup`). Die erzeugten S3-Zugangsdaten werden im Resultat zurückgegeben, damit nachfolgende Schritte (z.B. Ziel-Import) zugreifen können; die Löschung erfolgt nach dem eigentlichen Migrations-Workflow.

### 2. OS-Morphing
* **Status:** **Implementiert (Linux, Script-basiert für Windows)**  
  Die neuen Provider-Methoden `prepare_instance_for_os_morphing()` und `inject_drivers()` orchestrieren eine Worker-VM, hängen das Ziel-Volume an und führen über die STACKIT Run-Command API ein Python-Skript aus, das:
    * (Linux) Persistent-NIC-Regeln entfernt, `cloud-init`/Netplan/ifcfg-Dateien auf DHCP setzt, GRUB-Parameter (`net.ifnames=0 biosdevname=0`) injiziert und VirtIO-Module + `initramfs` neu baut. Optional kann ein eigenes Skript aus `os_morphing_assets.linux.script` eingebunden werden, welches die Standardlogik ersetzt.
    * (Windows) Ein benutzerdefiniertes Skript aus `os_morphing_assets.windows.script` ausführt. Dieses Script erhält Zugriff auf das Block-Device (`$CORIOLIS_DEVICE`) und die Job-Beschreibung und kann Treiberpakete/Cloudbase-init aus dem gleichen S3-Bucket laden. Damit lässt sich der bestehende Coriolis-Workflow (VirtIO-Treiber aktivieren, Registry anpassen, DHCP setzen) 1:1 portieren.
* **Voraussetzungen:**  
    * Linux-Gäste: unterstützte Dateisysteme (ext4/ext3/xfs/btrfs), `update-initramfs` oder `dracut` im Image.  
    * Windows-Gäste: ein eigenes Morphing-Skript und ggf. Treiberpakete im S3-Bucket; der Worker muss über `ntfs-3g`, `chntpw`, `zip/unzip` verfügen (siehe Worker-VM-Spezifikation).  
* **Hinweis:** Ohne Windows-Skript bricht der Provider den Morphing-Schritt ab. Damit ist klar ersichtlich, welche Assets noch gepflegt werden müssen.

### 3. Instanz-Erstellung
* **Status:** **Implementiert**
* **Funktion:** `create_instance()` nutzt jetzt den STACKIT Server-Endpoint (`bootVolume` Payload). Wenn ein bereits importiertes Volume übergeben wird, setzt der Provider automatisch `bootVolume.source = {"type": "volume", "id": ...}` und verzichtet auf `imageId`. Damit lassen sich Ziel-VMs direkt von einem zuvor transferierten Boot-Volume starten.
* **Hinweis:** Optional können weiterhin zusätzliche Volumes via `volumeIds` angehängt werden; `root_volume_size` greift nur, wenn kein eigenes Boot-Volume angegeben ist.

---

## 🟡 Teil 3: Nice-to-Have & Ausstehende Verbesserungen

Diese Funktionen sind nicht kritisch für eine Migration, würden den Provider aber robuster und benutzerfreundlicher machen.

### 1. Asynchrones Status-Polling
* **Status:** **Weitgehend Implementiert**
* **Funktion:** Power- (`start/stop`), Volume- (`create`) **und Snapshot-Operationen** (`create/delete`) blocken nun, bis der jeweilige Ressourcenstatus über die regulären GET-/LIST-Endpunkte den Zielzustand meldet. `_wait_for_snapshot_status()` nutzt `GET /snapshots/{id}` als Workaround, sodass kein separater `/tasks/{id}`-Workflow nötig ist.
* **Noch offen:** Für seltene Aktionen mit separaten Task-IDs (z.B. Image-Importe) könnten wir optional noch dediziertes Task-Polling ergänzen, ist aber aktuell nicht blocker.

### 2. Detailliertes Ressourcen-Mapping
* **Status:** **Implementiert (Labels)**
* **Funktion:** Die Wrapper-Klassen (`StackitInstance`, `StackitVolume`, `StackitNetwork`) mappen jetzt die STACKIT-Labels (`labels`), sodass Tagging-Informationen in Coriolis sichtbar und filterbar sind.
* **Grund (Nice-to-have):** Optional könnten künftig weitere Metadaten (Erstellungsdatum, detaillierte Netzwerk-IPs, Sicherheitsgruppen) ergänzt werden, die über die Labels hinausgehen.

### 3. UI-Kosmetik (Logo)
* **Status:** **NICHT Implementiert**
* **Funktion:** Ein STACKIT-Logo in der "New Cloud Endpoint"-Auswahl anzeigen.
* **Grund (Nice-to-have):** Rein kosmetisch. Wie besprochen, erfordert dies eine manuelle und riskante Bearbeitung der Coriolis-Frontend-Dateien auf dem Server.