Coriolis/provider_funktionsstatus.md

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.