From 6f9f861836db610d3671b818593ec163f02d3a62 Mon Sep 17 00:00:00 2001 From: Felix Kronlage-Dammers Date: Wed, 30 Oct 2024 09:58:00 +0100 Subject: [PATCH] Feat/add blog rookify (#1012) * feat: add blog entries about Rookify for german and english translations. Also include profile of R.A. te Boekhorst Signed-off-by: Boekhorst --------- Signed-off-by: Boekhorst Signed-off-by: Felix Kronlage-Dammers Signed-off-by: boekhorstb1 <91957243+boekhorstb1@users.noreply.github.com> Co-authored-by: Boekhorst Co-authored-by: boekhorstb1 <91957243+boekhorstb1@users.noreply.github.com> Co-authored-by: Kurt Garloff --- _i18n/de/_posts/blog/2024-10-08-rookify.md | 320 ++++++++++++++++++++ _i18n/en/_posts/blog/2024-10-08-rookify.md | 321 +++++++++++++++++++++ 2 files changed, 641 insertions(+) create mode 100644 _i18n/de/_posts/blog/2024-10-08-rookify.md create mode 100644 _i18n/en/_posts/blog/2024-10-08-rookify.md diff --git a/_i18n/de/_posts/blog/2024-10-08-rookify.md b/_i18n/de/_posts/blog/2024-10-08-rookify.md new file mode 100644 index 0000000000..1dc453a556 --- /dev/null +++ b/_i18n/de/_posts/blog/2024-10-08-rookify.md @@ -0,0 +1,320 @@ +--- +layout: post +title: "Rookify: Migration von Ceph-Ansible zu Rook" +category: tech +author: +- "Rafael te Boekhorst" +avatar: +- "rboekhorst.jpg" +about: +- "boekhorst" +--- + +Um den Übergang von Ceph-Ansible zu Rook zu erleichtern, hat SCS ein Migrationswerkzeug namens [Rookify](https://github.com/SovereignCloudStack/rookify) fast fertig entwickelt. Dieses Tool vereinfacht und optimiert den Migrationsprozess, sodass Benutzer problemlos von einer Ceph-Ansible-Installation zu Rook wechseln können. Das Tool befindet sich derzeit in einem ersten technischen Preview und wird getestet. + +## Funktionen und Design + +### Statemachine (Zustandsautomat) + +Rookify ist ein Python-Paket, das einen auf ['transitions'](https://github.com/pytransitions/transitions) basierenden Zustandsautomaten-Ansatz verwendet, um verschiedene Ressourcen (wie Monitore, Manager, OSDs, MDS und Andere) zu Rook zu migrieren. Jede dieser Ressourcen hat ein entsprechendes [Modul](https://github.com/SovereignCloudStack/rookify/tree/main/src/rookify/modules) in Rookify, das unabhängig oder in Kombination mit anderen Modulen ausgeführt werden kann. + +Es ist wichtig zu beachten, dass die meisten Module Abhängigkeiten zu anderen Modulen haben und diese bei Bedarf implizit ausführen. Zum Beispiel muss das `migrate_mons` Modul zuerst das `analyze_ceph` Modul ausführen (wie durch die [REQUIRES-Variable](https://github.com/SovereignCloudStack/rookify/blob/main/src/rookify/modules/migrate_monitors/main.py) angegeben). Dies ist notwendig, damit Rookify den aktuellen Standort der Monitore bestimmen und festlegen kann, wohin sie migriert werden sollen. + +Rookify kann durch Bearbeiten einer umfassenden `config.yaml`-Datei konfiguriert werden, wie zum Beispiel in der bereitgestellten [config.example.yaml](https://github.com/SovereignCloudStack/rookify/blob/main/config.example.yaml). Diese Konfigurationsdatei spezifiziert verschiedene Abhängigkeiten (wie SSH-Schlüssel, Kubernetes- und Ceph-Konfigurationen) und ermöglicht es Benutzern, einfach zu entscheiden, welche Module ausgeführt werden sollen (siehe den Abschnitt `migration_modules` unten im `config.yaml`). + +### Pickle-Unterstützung + +Rookify unterstützt optional (empfohlen) die Verwendung einer **Pickle-Datei** (siehe oben im Abschnitt `general` in `config.example.yaml`). Pickle ist ein Modul zur Objektserialisierung, dass den Fortschrittsstatus extern speichert, d.h. welche Module ausgeführt wurden und Informationen über die Zielmaschine. Das bedeutet: + +- Wenn eine laufende Migration aus irgendeinem Grund gestoppt wird, kann Rookify die Pickle-Datei verwenden, um vom gespeicherten Zustand fortzufahren. +- Wenn eine Migration in Teilen ausgeführt wird (z.B. Module werden inkrementell ausgeführt), ermöglicht es die Pickle-Datei den Zustand des Clusters, d.h. der Migration, zu speichern. + +⚠️ **Wichtig**: +Die Pickle-Datei sollte manuell gelöscht werden, wenn dieselbe Rookify-Installation verwendet werden soll, um mehr als ein Cluster zu migrieren, oder wenn sich das eine Cluster plötzlich erheblich geändert hat. + +### Ein einfaches CLI + +Derzeit bietet Rookify eine simple CLI-Schnittstelle, die durch Ausführen von `rookify` mit `-h` oder `--help` angezeigt werden kann: + +```bash +usage: Rookify [-h] [-d] [-m] [-s] + +Optionen: + -h, --help Zeigt diese Hilfemeldung an und beendet das Programm. + -d, --dry-run Vorab-Analyse der Daten und Validierung der Migration. + -m, --migrate Führe die Migration durch. + -s, --show-states Zeigt den Status der Module an. +``` + +Das Argument `-m` oder `--migrate` wurde hinzugefügt, um Rookify (wirklich) auszuführen, während die Ausführung ohne Argumente im Preflight-Modus läuft, d.h. mit `-d` oder `--dry-run`. + +Das Argument `-s` oder `--show-states` wurde hinzugefügt, um den Fortschritt zu verfolgen. Hierzu wird die Pickle-Datei ausgelesen. Anschließend berichtet jedes Modul über den bekannten Zustand auf `stdout`. + +### Rookify's Arbeitsablauf: Wie wird die Aufgabe erledigt? + +Die Hauptfunktion von Rookify ist es, alle Ressourcen von Ceph zu Rook zu migrieren. Schauen wir uns den Abschnitt migration_modules in der `config.yaml`-Datei an: + +```yaml +# config.yaml +migration_modules: +- migrate_mons +``` + +Diese Konfiguration lässt Rookify die folgenden Schritte ausführen: + +1. Preflight-Modus: Das `migrate_mons` Modul läuft zuerst im Preflight-Modus, der auch manuell mit dem Befehl `rookify --dry-run` ausgelöst werden kann. In dieser Phase führt Rookify die Preflight-Methoden für die konfigurierten Module und ihre abhängigen Module aus. Außerdem überprüft Rookify den Ausführungsstatus aus der Pickle-Datei. Wenn die Migration bereits erfolgreich abgeschlossen wurde, endet das Modul hier. +2. Abhängigkeitsprüfung: Wenn das `migrate_mons` Modul noch nicht ausgeführt wurde (angezeigt durch eine leere Pickle-Datei), überprüft Rookify auf Abhängigkeiten, z.B. andere Module, die zuerst ausgeführt werden müssen. Es führt diese Module zuerst im Preflight-Modus und dann in Echtzeit aus. Der Status jedes Moduls wird optional in der Pickle-Datei gespeichert. + 1. Das `analyze_ceph` Modul: Rookify erkennt, dass das `analyze_ceph` Modul in jedem Fall zuerst ausgeführt werden muss. Das `analyze_ceph` Modul sammelt Daten über die laufenden Ceph-Ressourcen und die Kubernetes-Umgebung mit dem dort laufendem Rook-Operator. Beachten Sie, dass `analyze_ceph` zuerst, wie bei jedem anderen Modul, im Preflight-Modus läuft. Es wird geprüft, ob der Zustand bereits in der Pickle-Datei erfasst wurde. Wenn kein Zustand gefunden wird, sammelt `analyze_ceph` die notwendigen Informationen. + 2. Das `k8s_prerequisites_check` Modul: Hier erfolgt die Validierung für die k8s-Namespaces, da der Cluster-Namespace manuell erstellt werden muss. Nur die CephCluster-Ressource wird im nächsten Schritt durch `create_rook_cluster` erzeugt. + 3. Das `create_rook_cluster` Module : Nach erfolgreicher Ausführung der `analyze_ceph` und `k8s_prerequisites_check` Module überprüft Rookify auf weitere Abhängigkeiten wie das `create_rook_cluster` Modul. Dieses Modul erstellt die `clustermap.yaml` für Rook basierend auf den Informationen aus `analyze_ceph` und `k8s_prerequisites_check`. +3. Migrationsausführung: Nach erfolgreicher Ausführung von `analyze_ceph` und `create_cluster` wird das `migrate_mons` Modul ausgeführt. Rookify fährt den ersten laufenden Ceph-Monitor auf dem ersten Worker-Node herunter (indem es `sudo systemctl disable --now ceph-mon.target` verwendet) und aktiviert sofort den entsprechenden Monitor in Rook (indem es seine Metadaten in der `clustermap.yaml` auf "true" setzt). +4. Monitor-Migration: Rookify setzt diesen Prozess für jeden Monitor fort, bis alle zu Rook migriert und in Betrieb genommen wurden. Optional kann der Zustand in der Pickle-Datei gespeichert werden. + +Für sowohl Manager als auch Monitore wird Rookify den gerade beschriebenen Ansatz verwenden: Es wird versuchen, die Ceph-Ressource auszuschalten, nachdem sichergestellt wurde, dass eine entsprechende Ressource im Rook-Cluster neu erstellt werden kann. Bei OSDs und MDSs ist der Migrationsalgorithmus jedoch etwas anders. + + +### Migration von OSDs + +Hier funktioniert der für Manager und Monitore beschriebene „Eins-nach-dem-anderen“-Algorithmus nicht, da Rook einen Container namens `rook-ceph-osd-prepare` verwendet, der immer versucht, alle OSDs auf einem Pfad zu finden und sie gleichzeitig zu erstellen. Beachten Sie, dass es Konfigurationsoptionen gibt, die den Eindruck erwecken, dies zu handhaben, wie `useAllNodes=false` und `useAllDevices=false` (siehe [rook docs](https://rook.io/docs/rook/latest-release/CRDs/Cluster/host-cluster/#all-devices)). Beide Variablen sind standardmäßig in der Rook-Bereitstellung von OSISM auf „false“ gesetzt, dennoch versucht `rook-ceph-osd-prepare`, alle OSDs pro Knoten zu scannen und zu verarbeiten. Dies bedeutet in der Praxis, dass ein `device is busy`-Fehler sowie ein Crashloop-Feedback auftreten werden. Dieses Verhalten wurde durch das Herunterfahren aller OSD-Dämonen pro Knoten entschärft: + +1. Alle OSD-Daemons pro Node müssen gleichzeitig ausgeschaltet werden. +2. Die Pfade der OSD-Geräte müssen einzeln an `prepare_osd` übergeben werden, um eine sequenzielle Verarbeitung zu erzwingen. +3. Warten, bis jeder OSD auf dem Knoten gestartet ist, bevor fortgefahren wird. + +### Migration von MDSs + +Der „Eins-nach-dem-anderen“-Algorithmus funktioniert hier ebenfalls nicht, da Rook möglicherweise Instanzen aktualisieren (also updaten) möchte, während die Migration im Gange ist. Dies kann zum Beispiel passieren, wenn eine MDS-Instanz des Ceph-Ansible-Deployments abgeschaltet wird und Rook diese Instanz innerhalb von Kubernetes neu erstellen will. Dann möchte Rook möglicherweise alle MDS-Instanzen aktualisieren und wird daher versuchen, alle Instanzen versuchen auszuschalten: auch diejenigen, die noch unter Ceph-Ansible laufen. Rook kann diese Instanzen nicht erreichen und es werden dadurch Abhängigkeiten innerhalb von Rook nicht aufgelöst. + +Eine Möglichkeit dieses Problem zu lösen wäre, alle MDS-Instanzen unter Ceph-Ansible auszuschalten und Rook zu erlauben, sie alle neu zu erstellen. Das würde jedoch zu minimalen Ausfallzeiten führen und Rookify strebt an, keine Ausfallzeiten zu verursachen. + +Deshalb verwendet Rookify derzeit den folgenden Ansatz: + +1. Zwei MDS-Instanzen (mindestens eine muss aktiv sein) werden unter Ceph-Ansible belassen, alle anderen werden ausgeschaltet. Zum Beispiel, im Falle von insgesamt drei MDS-Instanzen wird nur eine MDS-Instanz ausgeschaltet. +2. Von den verbliebenen zwei Instanzen wird nun die erste ebenfalls abgeschaltet aber anschließend in Rook zum Scheduling freigegeben, sodass eine Rook-Instanz startet. Auf diesen Start wird gewartet, bevor die zweite (verbliebene) Instanz abgeschaltet und in Rook aktiviert wird. Alle weiteren Instanzen werden anschließend in Rook abgebildet. + +## Testlauf: Ausprobieren und beim Testen helfen + +Um mit Rookify zu beginnen, stellen Sie sicher, dass Sie die [README.md](https://github.com/SovereignCloudStack/rookify/blob/main/README.md) im Repository durchlesen. + +Wenn Sie den aktuellen Stand von Rookify testen möchten (sehr geschätzt - melden Sie gerne [Issues](https://github.com/SovereignCloudStack/rookify/issues) bei Github), können Sie das Testbed von OSISM verwenden. + +### Testbed-Einrichtung + +ℹ️ **Info:** + Das OSISM-Testbed ist für Testzwecke gedacht, was bedeutet, dass es instabil sein kann. Wenn Ceph und K3s nicht fehlerfrei bereitgestellt werden können, müssen Sie möglicherweise auf eine Fehlerbehebung warten oder eine Umgehungslösung finden, um Rookify zu testen. + +Um das Testbed einzurichten, konsultieren Sie zunächst die [Testbed-Dokumentation von OSISM](https://osism.tech/docs/guides/other-guides/testbed) um sicherzustellen, dass Sie alle Anforderungen erfüllen. Wenn alles in Ordnung ist, klonen Sie das Repository und verwenden Sie make ceph, um ein Ceph-Testbed einzurichten. Dieser Befehl zieht automatisch die notwendigen Ansible-Rollen, bereitet eine virtuelle Umgebung vor, baut die Infrastruktur mit OpenStack, erstellt einen Manager-Node und stellt Ceph auf drei Worker-Nodes bereit: + +```bash +git clone github.com:osism/testbed.git +make ceph +``` + +Sobald die Infrastruktur für Ceph und das Testbed bereitgestellt wurde, melden Sie sich mit `make login` an und stellen Sie K3s sowie einen Rook-Operator bereit: + +```bash +make login +osism apply k3s +osism apply rook-operator +``` + +Wenn Sie Konfigurationen ändern möchten, z.B. eine Rook-Einstellung, gehen Sie zu `/opt/configuration/environments/rook/` und sehen Sie in der [Dokumentation zu Rook von OSISM](https://osism.tech/docs/guides/configuration-guide/rook) nach, um verschiedene Einstellungen zu finden. + +### Rookify-Einrichtung/Konfiguration für das Testbed von OSISM + +#### 1. Klonen des Rookify-Repository's + +Führen Sie `make setup` aus, damit automatisch das Rookify-Repository gekloned und aufgesetzt wird: es erstellt automatisch eine virtuelle Python-Umgebung, lädt die nötigen Python-Bybliotheken herunter und baut damit ein Python Packet für Rookify in `./.venv/bin/rookify`. Sie können auch die andere Hilfefunktionen des Makefile auflisten lassen, indem Sie einfach `make` (das gleiche wie `make help`) im Stammverzeichnis des Arbeitsverzeichnisses ausführen. + +```bash +git clone https://github.com/SovereignCloudStack/rookify +cd rookify +make setup +``` + +ℹ️ **Info:** + Wenn Sie einen Fehler der `python-rados`-Bibliothek erhalten, können Sie `make check-radoslib` ausführen, um zu prüfen, ob die Bibliothek lokal installiert ist. Wenn nicht, installieren Sie das Paket manuell. Die python-rados-Bibliothek sollte zum Zeitpunkt des Schreibens Version 2.0.0 sein (überprüfen Sie die README.md-Datei von Rookify für die aktuellste Dokumentation). Die Bibliothek konnte nicht in die Einrichtung integriert werden, da Ceph derzeit keine Builds für pip anbietet. + +#### 2. Konfigurieren von Rookify + +Kopieren Sie `config.example.osism.yaml` nach `config.yaml`und ändern Sie die verschiedenen Konfigurationseinstellungen nach Bedarf. Rookify benötigt Zugriff auf einen SSH-Schlüssel (z.B. die `.id_rsa`-Datei im Terraform-Verzeichnis im Testbed-Repository), Ceph-Konfigurationsdateien (siehe `/etc/ceph/` auf einem der Worker-Nodes) und Kubernetes-Dateien (z.B. `~/.kube/config` vom Manager-Node). Prüfen Sie gegebenfalls, ob das Makefile Hilfsfunktionen enthält, die Ihnen helfen können. + +📝 **Hinweis:** +Stellen Sie sicher, dass Rookify eine Verbindung zum Testbed herstellen kann. Weitere Informationen zum Einrichten einer VPN-Verbindung finden Sie in der [OSISM-Dokumentation](https://osism.tech/docs/guides/other-guides/testbed/#vpn-access). + +```yaml +general: + machine_pickle_file: data.pickle + +logging: + level: INFO # Stufe, auf der das Logging beginnen soll + format: + time: "%Y-%m-%d %H:%M.%S" # anderes Beispiel: "iso" + renderer: console # oder: json + +ceph: + config: ./.ceph/ceph.conf + keyring: ./.ceph/ceph.client.admin.keyring + +# korrekten Pfad zum privaten Schlüssel einfügen +ssh: + private_key: /home/USER/.ssh/cloud.private + hosts: + testbed-node-0: + address: 192.168.16.10 + user: dragon + testbed-node-1: + address: 192.168.16.11 + user: dragon + testbed-node-2: + address: 192.168.16.12 + user: dragon + +kubernetes: + config: ./k8s/config + +rook: + cluster: + name: osism-ceph + namespace: rook-ceph + mds_placement_label: node-role.osism.tech/rook-mds + mgr_placement_label: node-role.osism.tech/rook-mgr + mon_placement_label: node-role.osism.tech/rook-mon + osd_placement_label: node-role.osism.tech/rook-osd + rgw_placement_label: node-role.osism.tech/rook-rgw + ceph: + image: quay.io/ceph/ceph:v18.2.1 + +migration_modules: # legt fest, welche Module ausgeführt werden sollen. Beachten Sie, dass einige der Module andere Module erfordern, die ebenfalls ausgeführt werden müssen. Dies geschieht automatisch. +- analyze_ceph +``` + +#### 3. Rookify ausführen: + +Jetzt können Sie endlich Rookify ausführen um es zu testen. Rookify erlaubt die Verwendung von `--dry-run`, um Module im Preflight-Modus auszuführen. Beachten Sie, dass Rookify die verschiedenen Module immer zuerst im Preflight-Modus ausführt bevor anschließend, bei fehlerfreiem Durchlauf, eine Migration gestartet wird. + +Wenn alles korrekt eingerichtet ist, können Sie Rookify ohne Argumente ausführen oder sie wagen es explizit `--migrate` als Argument zu geben. In diesem Fall machen Sie nichts kaput, wenn Sie das `analyze_ceph`-Modul auszuführen, da dieses keine kritischen Änderungen vornimmt: + +📝 **Hinweis:** + Ohne Argumente wird Rookify per default im Preflight-Modus laufen (es wird dann `--dry-run` hinzugefügt). + +```bash +# Preflight-Modus +.venv/bin/rookify --dry-run +# Reales Ausführen: das analyze_ceph Modul sollte nichts kaputt machen +.venv/bin/rookify --migrate +``` + +⚠️ **Wichtig:** +Es wird empfohlen, jedes Modul zuerst im Preflight-Modus auszuführen, um echte Änderungen zu vermeiden. + +Sie sollten dann folgende Ausgabe auf der Konsole sehen: + +```bash +.venv/bin/rookify +2024-09-02 15:21.37 [info ] Execution started with machine pickle file +2024-09-02 15:21.37 [info ] AnalyzeCephHandler ran successfully. +``` + +Beachten Sie, dass es jetzt eine Datei "data.pickle" (je nach dem wie es benannt wurde im `config.yaml`) im Stammverzeichnis des Arbeitsverzeichnisses gibt. Diese Datei sollte Daten enthalten: + +```bash +du -sh data.pickle +8.0K data.pickle +``` + +An diesem Punkt können wir die Datei `config.yaml` erneut bearbeiten, um die osds-, mds-, mgr- und rgw- Ressourcen zu migrieren: + +``` +migration_modules: +- analyze_ceph +- create_rook_cluster +- migrate_mons +- migrate_osds +- migrate_osd_pools +- migrate_mds +- migrate_mds_pools +- migrate_mgrs +- migrate_rgws +- migrate_rgw_pools +``` + +ℹ️ **Info:** + Einige der Module sind redundant in dem Sinne, dass ihre `REQUIRED`-Variablen die Module bereits als ihre Abhängigkeiten enthalten. Zum Beispiel hat `migrate_osds` die folgende `REQUIRED`-Variable: `REQUIRES = [„migrate_mons“]`, und `migrate_mons` hat `REQUIRES = [„analyze_ceph“, „create_rook_cluster“]`. Man könnte also die ersten drei Module aus der Konfiguration entfernen. Die zusätzliche Erwähnung der Module kann hier aber die Übersichtlichkeit für den Leser verbessern. Tatsächlich wird Rookify die Module nur einmal ausführen, so dass es nicht schadet, sie in der `config.yaml` hinzuzufügen. + +Wir können Rookify zunächst mit `pre-flight` starten, um zu prüfen, ob alles in Ordnung ist und es dann explizit mit dem Argument `--migrate` versehen, um die wirkliche Migration zu starten. Als Ergebnis sollten wir folgenden Output sehen: + +``` +.venv/bin/rookify +2024-09-04 08:52.02 [info ] Execution started with machine pickle file +2024-09-04 08:52.04 [info ] AnalyzeCephHandler ran successfully. +2024-09-04 08:52.04 [info ] Validated Ceph to expect cephx auth +2024-09-04 08:52.04 [warning ] Rook Ceph cluster will be configured without a public network and determine it automatically during runtime +2024-09-04 08:52.04 [info ] Rook Ceph cluster will be configured without a cluster network +2024-09-04 08:52.11 [warning ] ceph-mds filesystem 'cephfs' uses an incompatible pool metadata name 'cephfs_metadata' and can not be migrated to Rook automatically +2024-09-04 08:52.16 [info ] Creating Rook cluster definition +2024-09-04 08:52.16 [info ] Waiting for Rook cluster created +2024-09-04 08:52.16 [info ] Migrating ceph-mon daemon 'testbed-node-0' +2024-09-04 08:52.32 [info ] Disabled ceph-mon daemon 'testbed-node-0' +2024-09-04 08:53.45 [info ] Quorum of 3 ceph-mon daemons successful +2024-09-04 08:53.45 [info ] Migrating ceph-mon daemon 'testbed-node-1' +2024-09-04 08:54.07 [info ] Disabled ceph-mon daemon 'testbed-node-1' +2024-09-04 08:54.44 [info ] Quorum of 3 ceph-mon daemons successful +2024-09-04 08:54.44 [info ] Migrating ceph-mon daemon 'testbed-node-2' +2024-09-04 08:55.04 [info ] Disabled ceph-mon daemon 'testbed-node-2' +2024-09-04 08:55.52 [info ] Quorum of 3 ceph-mon daemons successful +2024-09-04 08:55.52 [info ] Migrating ceph-osd host 'testbed-node-0' +2024-09-04 08:55.55 [info ] Disabled ceph-osd daemon 'testbed-node-0@0' +2024-09-04 08:55.57 [info ] Disabled ceph-osd daemon 'testbed-node-0@4' +2024-09-04 08:55.57 [info ] Enabling Rook based ceph-osd node 'testbed-node-0' +2024-09-04 08:57.00 [info ] Rook based ceph-osd daemon 'testbed-node-0@0' available +2024-09-04 08:57.02 [info ] Rook based ceph-osd daemon 'testbed-node-0@4' available +2024-09-04 08:57.02 [info ] Migrating ceph-osd host 'testbed-node-1' +2024-09-04 08:57.05 [info ] Disabled ceph-osd daemon 'testbed-node-1@1' +2024-09-04 08:57.07 [info ] Disabled ceph-osd daemon 'testbed-node-1@3' +2024-09-04 08:57.07 [info ] Enabling Rook based ceph-osd node 'testbed-node-1' +2024-09-04 08:58.46 [info ] Rook based ceph-osd daemon 'testbed-node-1@1' available +2024-09-04 08:58.46 [info ] Rook based ceph-osd daemon 'testbed-node-1@3' available +2024-09-04 08:58.46 [info ] Migrating ceph-osd host 'testbed-node-2' +2024-09-04 08:58.48 [info ] Disabled ceph-osd daemon 'testbed-node-2@2' +2024-09-04 08:58.50 [info ] Disabled ceph-osd daemon 'testbed-node-2@5' +2024-09-04 08:58.50 [info ] Enabling Rook based ceph-osd node 'testbed-node-2' +2024-09-04 09:00.25 [info ] Rook based ceph-osd daemon 'testbed-node-2@2' available +2024-09-04 09:00.27 [info ] Rook based ceph-osd daemon 'testbed-node-2@5' available +2024-09-04 09:00.27 [info ] Migrating ceph-mds daemon at host 'testbed-node-0' +2024-09-04 09:00.27 [info ] Migrating ceph-mds daemon at host 'testbed-node-1' +2024-09-04 09:00.27 [info ] Migrating ceph-mds daemon at host 'testbed-node-2' +2024-09-04 09:00.27 [info ] Migrating ceph-mgr daemon at host'testbed-node-0' +2024-09-04 09:01.03 [info ] Disabled ceph-mgr daemon 'testbed-node-0' and enabling Rook based daemon +2024-09-04 09:01.20 [info ] 3 ceph-mgr daemons are available +2024-09-04 09:01.20 [info ] Migrating ceph-mgr daemon at host'testbed-node-1' +2024-09-04 09:01.51 [info ] Disabled ceph-mgr daemon 'testbed-node-1' and enabling Rook based daemon +2024-09-04 09:02.09 [info ] 3 ceph-mgr daemons are available +2024-09-04 09:02.09 [info ] Migrating ceph-mgr daemon at host'testbed-node-2' +2024-09-04 09:02.41 [info ] Disabled ceph-mgr daemon 'testbed-node-2' and enabling Rook based daemon +2024-09-04 09:03.00 [info ] 3 ceph-mgr daemons are available +2024-09-04 09:03.00 [info ] Migrating ceph-rgw zone 'default' +2024-09-04 09:03.00 [info ] Migrated ceph-rgw zone 'default' +2024-09-04 09:03.00 [info ] Migrating ceph-osd pool 'backups' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'backups' +2024-09-04 09:03.01 [info ] Migrating ceph-osd pool 'volumes' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'volumes' +2024-09-04 09:03.01 [info ] Migrating ceph-osd pool 'images' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'images' +2024-09-04 09:03.01 [info ] Migrating ceph-osd pool 'metrics' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'metrics' +2024-09-04 09:03.01 [info ] Migrating ceph-osd pool 'vms' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'vms' +2024-09-04 09:03.01 [info ] Migrating ceph-rgw daemon at host 'testbed-node-2' +2024-09-04 09:04.27 [info ] Disabled ceph-rgw host 'testbed-node-2' +2024-09-04 09:04.35 [info ] Rook based RGW daemon for node 'testbed-node-2' available +2024-09-04 09:04.35 [info ] Migrating ceph-rgw daemon at host 'testbed-node-1' +2024-09-04 09:04.41 [info ] Disabled ceph-rgw host 'testbed-node-1' +2024-09-04 09:05.09 [info ] Rook based RGW daemon for node 'testbed-node-1' available +2024-09-04 09:05.09 [info ] Migrating ceph-rgw daemon at host 'testbed-node-0' +2024-09-04 09:05.13 [info ] Disabled ceph-rgw host 'testbed-node-0' +2024-09-04 09:05.19 [info ] Rook based RGW daemon for node 'testbed-node-0' available +``` + +Wow! Wir sind von Ceph-Ansible nach Rook migriert! +Wenn wir jetzt in das Testbed einloggen können wir die "Health" des clusters nochmal mit `ceph -s` kontrollieren. Mit `kubectl` kann man noch checken, das alle Pods da sind. diff --git a/_i18n/en/_posts/blog/2024-10-08-rookify.md b/_i18n/en/_posts/blog/2024-10-08-rookify.md new file mode 100644 index 0000000000..cbfc8bfc32 --- /dev/null +++ b/_i18n/en/_posts/blog/2024-10-08-rookify.md @@ -0,0 +1,321 @@ +--- +layout: post +title: "Rookify: Migrating from Ceph-Ansible to Rook" +category: tech +author: +- "Rafael te Boekhorst" +avatar: +- "rboekhorst.jpg" +about: +- "boekhorst" +--- + +To facilitate the transition from Ceph-Ansible to Rook, SCS has almost finished developing a migration tool called [Rookify](https://github.com/SovereignCloudStack/rookify). This tool simplifies and streamlines the migration process, making it easier for users to switch from a Ceph-Ansible deployment to Rook. The tool is now under first technical preview and is being tested. + +## Features and Design + +### Statemachine + +Rookify is a python package that uses a **state-machine** based on the [transitions-library](https://github.com/pytransitions/transitions) to migrate the various resources (such as mons, mgrs, osds, mds and anything else) to Rook. Each of these resources has a corresponding [module](https://github.com/SovereignCloudStack/rookify/tree/main/src/rookify/modules) in Rookify, which can be executed independently or in combination with other modules. + +It’s important to note that most modules have dependencies on other modules and will implicitly run them as needed. For example, the `mgirate-mons` module needs the `analyze-ceph` module to run first (as indicated by the [REQUIRES variable](https://github.com/SovereignCloudStack/rookify/blob/main/src/rookify/modules/migrate_monitors/main.py)).This is necessary for Rookify to determine the current location of the mons and where they should be migrated to. + +Rookify can be configured by editing a comprehensive `config.yaml` file, such as the provided [confing.example.yaml](https://github.com/SovereignCloudStack/rookify/blob/main/config.example.yaml). This configuration file specifies various configuration-dependencies (like SSH keys, Kubernetes and Ceph configurations) and allows users to easily decide which modules should be run (see the `migration_modules` section below in `config.yaml`). + +### Pickle support + +Rookify optionally (and recommended) supports using a **pickle file** (see on top below the `general` section in config.example.yaml). [Pickle](https://docs.python.org/3/library/pickle.html) is a model for object serialization that saves the state of progress externally, i.e. which modules have been run and information about the target machine. This means that Rookify can 'save' its progress: +- if a running migration is for some reason stopped, Rookify can use the pickle file to continue from the saved state. +- if a migration is run in parts (e.g. modules are run incrementally), then the pickle file allows to save the state of the cluster, i.e. the migration. + +⚠️ **Important:**: +This means that if the same Rookify installation should be used to migrate more than one cluster, or the one cluster has significantly changed suddenly, the pickle file should be deleted manually. + + +### A simple CLI + +Currently, Rookify only offers a straightforward CLI interface, which can be displayed by running `rookify` with `-h` or `--help`: + +``` +usage: Rookify [-h] [-d] [-m] [-s] + +options: + -h, --help show this help message and exit + -d, --dry-run Preflight data analysis and migration validation. + -m, --migrate Run the migration. + -s, --show-states Show states of the modules. +``` + +The `-m` or `--migrate` argument has been added to (really) execute Rookify, while execution without arguments runs in preflight mode, i.e. with `-d` or `--dry-run`. + +The `-s` or `--show-states` has been added to track the state of progress. The pickle file is read out for this purpose. Each module then reports the known status on `stdout`. + +### Rookify's general workflow: migrating monitors? + +Rookify's main function is to migrate all of Ceph's resources to Rook. Let's take a look at the `migration_modules` section in the `config.yaml` file: + +```yaml +# config.yaml +migration_modules: +- migrate_mons +``` + +This configuration instructs Rookify to perform the following steps: + +1. Preflight Mode: The `migrate_mons` module first runs in a preflight mode, which can also be manually triggered using the `rookify --dry-run` command. During this phase, Rookify runs the preflight methods for the configured modules and their dependent modules. If the migration has already been successfully completed, the module stops here. +2. Dependency Check: If the migrate_mons module has not been run before (indicated by an empty pickle file), Rookify checks for dependencies, e.g. other modules that need to be run first. It execute those modules, first in preflight mode and then for real. The state of each module will optionally be saved in the pickle file. + 1. `ceph-analyze` module: Rookify identifies that the `analyze-ceph` module needs to be run first in any case. The `analyze-ceph` module collects data on the running Ceph resources and the Kubernetes environment with the Rook operator. Note that, like any other module, `ceph-analyze` first runs in preflight mode to check if the state has already been captured in the pickle file. If no state is found, `analyze-ceph` gathers the necessary information. + 2. `k8s_prerequisites_check` module: Validation for k8s namespace is done here, as it is required that the cluster namespace has been created manually. Only the CephCluster resource is generated in the next step by `create_rook_cluster`. + 3. `create_rook_cluster` module: After successfully running the `analyze-ceph` and `k8s_prerequisites_check` modules, Rookify will check for other dependencies, such as the `create_rook_cluster` module. This module creates the `clustermap.yaml` for Rook based on information from `analyze-ceph` and `k8s_prerequisites_check`. +3. Migration Execution: Following the successful execution of `analyze_ceph` and `create_cluster`, the `migrate_mons` module is executed. Rookify shuts down the first running Ceph monitor on the first worker node (using `sudo systemctl disable --now ceph-mon.target`) and immediately activates the equivalent monitor in Rook (by setting its metadata in the clustermap.yaml to true). +4. Monitor Migration: Rookify continues this process for each monitor until all have been migrated to Rook and are running. Optionally, the state can be saved in the pickle file. If, for example, the pickle file contains a finished state of migrate_mons, it will skip this module and only check if it has indeed bin run successfully. + +For both managers and monitors, Rookify will use the just described approach: it will try to switch of the ceph resource after it has made sure that it can re-create an equivalent in the Rook cluster. For OSDs and MDS the migratory algorithm is a bit different. + +### Migrating OSDs + +Here the "one-by-one"-algorithm described for managers and monitors does not work, because Rook has a container called `rook-ceph-osd-prepare` that always tries to find all osds on a path and build all of them at once. Note that there are configuration options that give the impression to handle this, like `useAllNodes=false` und `useAllDevices=false` (see [rook docs](https://rook.io/docs/rook/latest-release/CRDs/Cluster/host-cluster/#all-devices)). Both variables are set to false per default in the Rook deployment of OSISM, nevertheless `rook-ceph-osd-prepare` tries to scan and process all osds per node. This means in effect, that a `device is busy`-error will occur as well as a crashloop-feedback. This behavior has been mitigated by shutting down all OSD daemons per node: + +1. all OSD daemons per node have to switched of at once +2. paths of osd devices have to be fed one by to `rook-ceph-osd-prepare` to enforce sequential processing +3. wait for each osds on the node to be started before continuing + +### Migrating MDSs + +The "one-by-one"-algorithm described for managers and monitors does not work here either, because Rook might want to update instances while the migration is in process: This might happen, for example, if one MDS's instance of the Ceph-Ansible deployment is shutoff and Rook is allowed to rebuild this instance within Kubernetes. Then Rook might want to update all MDS instances and will consequently try to switch of all the instances in order to update them: also the ones that are still running under Ceph-Ansible. Consequently, Rook will not reach these instances and errors will be thrown. + +One way to solve this problem, would be to switch of all mds-instances under Ceph-Ansible and let Rook rebuild all of them. That would cause some minimal downtime though, and Rookify strives to cause 0 downtime. + +That is why Rookify currently uses the following approach: +1. Two mds instances (at least one has to be active) will be left under Ceph-Ansible, all others will be switched off. For example, in case of a total of three mds instances, only one mds instance will be switched off. +2. Of the remaining two instances, the first one will now also be shut down and consequently made available for scheduling in Rook, so that a Rook instance starts. The system waits for this start before the last (remaining) instance is shut down and activated in Rook. All further instances will then be mapped in Rook. + +## Test run: Give it a try and help with testing process + +To get started with Rookify, make sure to checkout the [README.md](https://github.com/SovereignCloudStack/rookify/blob/main/README.md) in the repository. + +If you'd like to try to test the current state of Rookify (much appreciated - feel free to report any [issues](https://github.com/SovereignCloudStack/rookify/issues) to Github), you can use the testbed of OSISM. + +### Testbed setup + +ℹ️ **Info:** + The OSISM testbed is intended for testing purposes, which means it may be unstable. If Ceph and K3s cannot be deployed without errors, you may need to wait for a fix or find a workaround to test Rookify. + +In order to setup the testbed, first consult [OSISM's testbed documentation](https://osism.tech/docs/guides/other-guides/testbed) to ensure you meet all requirements. If everything is in order, clone the repository and use make ceph to set up a Ceph testbed. This command will automatically pull the necessary Ansible roles, prepare a virtual environment, build the infrastructure with OpenStack, create a manager node, and deploy Ceph on three worker nodes: + +```bash +git clone github.com:osism/testbed.git +make ceph +``` + +Once the infrastructure for Ceph and the testbed has been deployed, log in with make login and deploy K3s as well as a Rook operator: + +```bash +make login +osism apply k3s +osism apply rook-operator +``` + +If you want to modify any configurations, such as a Rook setting, refer to `/opt/configuration/environments/rook/` and check [OSISM's documentation on Rook](https://osism.tech/docs/guides/configuration-guide/rook) for various settings. + +### Rookify Setup/Configuration for OSISM's Testbed + +#### 1. Clone the Rookify Repository + +Start by cloning the Rookify repository, setting it up, and building the Python package in a virtual environment using the Makefile. You can simply run `make` without any arguments to see a list of helper functions that can assist you in setting up and configuring Rookify. The command `make setup` downloads the necessary virtual environment libraries and installs the Rookify package into `.venv/bin/rookify` within the working directory: + +```bash +git clone https://github.com/SovereignCloudStack/rookify +cd rookify +make setup +``` + +ℹ️ **Info:** + If you encounter an error from the `python-rados` library, you can run `make check-radoslib` to check if the library is installed locally. If not, install the package manually. The python-rados library should be version 2.0.0 at the time of writing (check the `README.md` file of Rookify for the most up-to-date documentation). The library could not be integrated within the setup because Ceph currently offers no builds for pip. + +#### 2. Configure Rookify + +Copy `config.example.osism.yaml` to `config.yaml` and modify the various configuration settings as needed. Rookify will require access to an SSH key (e.g., the `.id_rsa` file in the Terraform directory in the testbed repository), Ceph configuration files (see `/etc/ceph/` on one of the worker nodes), and Kubernetes files (e.g., `~/.kube/config` from the manager node). Check if the Makefile contains any helper functions to assist you: run make in the root of the working directory to see all options that the Makefile offers. + +📝 **Note:** + Ensure that Rookify can connect to the testbed. Refer to [OSISM-documentation](https://osism.tech/docs/guides/other-guides/testbed/#vpn-access) about how to setup a VPN connection. + +```yaml +general: + machine_pickle_file: data.pickle + +logging: + level: INFO # level at which logging should start + format: + time: "%Y-%m-%d %H:%M.%S" # other example: "iso" + renderer: console # or: json + +ceph: + config: ./.ceph/ceph.conf + keyring: ./.ceph/ceph.client.admin.keyring + +# fill in correct path to private key +ssh: + private_key: /home/USER/.ssh/cloud.private + hosts: + testbed-node-0: + address: 192.168.16.10 + user: dragon + testbed-node-1: + address: 192.168.16.11 + user: dragon + testbed-node-2: + address: 192.168.16.12 + user: dragon + +kubernetes: + config: ./k8s/config + +rook: + cluster: + name: osism-ceph + namespace: rook-ceph + mds_placement_label: node-role.osism.tech/rook-mds + mgr_placement_label: node-role.osism.tech/rook-mgr + mon_placement_label: node-role.osism.tech/rook-mon + osd_placement_label: node-role.osism.tech/rook-osd + rgw_placement_label: node-role.osism.tech/rook-rgw + ceph: + image: quay.io/ceph/ceph:v18.2.1 + +migration_modules: # this sets the modules that need to be run. Note that some of the modules require other modules to be run as well, this will happen automatically. +- analyze_ceph +``` + +#### 3. Run Rookify: + +Finally, run Rookify to test it. Rookify allows the use of `--dry-run` to run modules in preflight mode. Note that Rookify always checks for a successful run of the various modules in preflight mode before starting the migration. + +Additionally it is always safe to run the `analyze_ceph` module, as it will not make any real changes. + +📝 **Note:** + By default, Rookify runs in preflight mode. If you execute Rookify without any arguments `--dry-run` will be appended. + +To be on the secure side, you can now run Rookify in preflight mode. In this case you could also execute it directly, i.e. by adding the argument `--migrate` (because the `analyze_ceph` module does not break anything): + +```bash +# Preflight mode +.venv/bin/rookify --dry-run +# Execution mode +.venv/bin/rookify --migrate +``` + +⚠️ **Important:** +It is advised to run any module in preflight mode first, to avoid any real changes. + +If all is setup correctly you will see an output similar to this: + +```bash +.venv/bin/rookify --migrate +2024-09-02 15:21.37 [info ] Execution started with machine pickle file +2024-09-02 15:21.37 [info ] AnalyzeCephHandler ran successfully. +``` + +Note that now there is a `data.pickle` file in the root of your working directory. The file should contain data: + +```bash +du -sh data.pickle +8.0K data.pickle +``` + +At this point we can re-edit the `config.yaml` file to migrate the osds, mds, managers and radosgateway resources: + +``` +migration_modules: +- analyze_ceph +- create_rook_cluster +- migrate_mons +- migrate_osds +- migrate_osd_pools +- migrate_mds +- migrate_mds_pools +- migrate_mgrs +- migrate_rgws +- migrate_rgw_pools +``` + +ℹ️ **Info:** + Some of these are redundant in the sense that their `REQUIRED` variables contain the modules as their dependencies already. For example `migrate_osds` has the following `REQUIRED`-variable: `REQUIRES = ["migrate_mons"]`, and `migrate_mons` has `REQUIRES = ["analyze_ceph", "create_rook_cluster"]`. So it would be fine to skip the first three modules. Still, the extra mention of the modules could improve clarity for the reader. In effect Rookify will run the modules only once, so it does not hurt to add them in the `config.yaml`. + + +We can first run Rookify with in preflight mode ( `--dry-run` ) to check if all is ok and then run it with `--migration`. Executing Rookify should then give you an output similar to this: + +``` +.venv/bin/rookify --migration +2024-09-04 08:52.02 [info ] Execution started with machine pickle file +2024-09-04 08:52.04 [info ] AnalyzeCephHandler ran successfully. +2024-09-04 08:52.04 [info ] Validated Ceph to expect cephx auth +2024-09-04 08:52.04 [warning ] Rook Ceph cluster will be configured without a public network and determine it automatically during runtime +2024-09-04 08:52.04 [info ] Rook Ceph cluster will be configured without a cluster network +2024-09-04 08:52.11 [warning ] ceph-mds filesystem 'cephfs' uses an incompatible pool metadata name 'cephfs_metadata' and can not be migrated to Rook automatically +2024-09-04 08:52.16 [info ] Creating Rook cluster definition +2024-09-04 08:52.16 [info ] Waiting for Rook cluster created +2024-09-04 08:52.16 [info ] Migrating ceph-mon daemon 'testbed-node-0' +2024-09-04 08:52.32 [info ] Disabled ceph-mon daemon 'testbed-node-0' +2024-09-04 08:53.45 [info ] Quorum of 3 ceph-mon daemons successful +2024-09-04 08:53.45 [info ] Migrating ceph-mon daemon 'testbed-node-1' +2024-09-04 08:54.07 [info ] Disabled ceph-mon daemon 'testbed-node-1' +2024-09-04 08:54.44 [info ] Quorum of 3 ceph-mon daemons successful +2024-09-04 08:54.44 [info ] Migrating ceph-mon daemon 'testbed-node-2' +2024-09-04 08:55.04 [info ] Disabled ceph-mon daemon 'testbed-node-2' +2024-09-04 08:55.52 [info ] Quorum of 3 ceph-mon daemons successful +2024-09-04 08:55.52 [info ] Migrating ceph-osd host 'testbed-node-0' +2024-09-04 08:55.55 [info ] Disabled ceph-osd daemon 'testbed-node-0@0' +2024-09-04 08:55.57 [info ] Disabled ceph-osd daemon 'testbed-node-0@4' +2024-09-04 08:55.57 [info ] Enabling Rook based ceph-osd node 'testbed-node-0' +2024-09-04 08:57.00 [info ] Rook based ceph-osd daemon 'testbed-node-0@0' available +2024-09-04 08:57.02 [info ] Rook based ceph-osd daemon 'testbed-node-0@4' available +2024-09-04 08:57.02 [info ] Migrating ceph-osd host 'testbed-node-1' +2024-09-04 08:57.05 [info ] Disabled ceph-osd daemon 'testbed-node-1@1' +2024-09-04 08:57.07 [info ] Disabled ceph-osd daemon 'testbed-node-1@3' +2024-09-04 08:57.07 [info ] Enabling Rook based ceph-osd node 'testbed-node-1' +2024-09-04 08:58.46 [info ] Rook based ceph-osd daemon 'testbed-node-1@1' available +2024-09-04 08:58.46 [info ] Rook based ceph-osd daemon 'testbed-node-1@3' available +2024-09-04 08:58.46 [info ] Migrating ceph-osd host 'testbed-node-2' +2024-09-04 08:58.48 [info ] Disabled ceph-osd daemon 'testbed-node-2@2' +2024-09-04 08:58.50 [info ] Disabled ceph-osd daemon 'testbed-node-2@5' +2024-09-04 08:58.50 [info ] Enabling Rook based ceph-osd node 'testbed-node-2' +2024-09-04 09:00.25 [info ] Rook based ceph-osd daemon 'testbed-node-2@2' available +2024-09-04 09:00.27 [info ] Rook based ceph-osd daemon 'testbed-node-2@5' available +2024-09-04 09:00.27 [info ] Migrating ceph-mds daemon at host 'testbed-node-0' +2024-09-04 09:00.27 [info ] Migrating ceph-mds daemon at host 'testbed-node-1' +2024-09-04 09:00.27 [info ] Migrating ceph-mds daemon at host 'testbed-node-2' +2024-09-04 09:00.27 [info ] Migrating ceph-mgr daemon at host'testbed-node-0' +2024-09-04 09:01.03 [info ] Disabled ceph-mgr daemon 'testbed-node-0' and enabling Rook based daemon +2024-09-04 09:01.20 [info ] 3 ceph-mgr daemons are available +2024-09-04 09:01.20 [info ] Migrating ceph-mgr daemon at host'testbed-node-1' +2024-09-04 09:01.51 [info ] Disabled ceph-mgr daemon 'testbed-node-1' and enabling Rook based daemon +2024-09-04 09:02.09 [info ] 3 ceph-mgr daemons are available +2024-09-04 09:02.09 [info ] Migrating ceph-mgr daemon at host'testbed-node-2' +2024-09-04 09:02.41 [info ] Disabled ceph-mgr daemon 'testbed-node-2' and enabling Rook based daemon +2024-09-04 09:03.00 [info ] 3 ceph-mgr daemons are available +2024-09-04 09:03.00 [info ] Migrating ceph-rgw zone 'default' +2024-09-04 09:03.00 [info ] Migrated ceph-rgw zone 'default' +2024-09-04 09:03.00 [info ] Migrating ceph-osd pool 'backups' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'backups' +2024-09-04 09:03.01 [info ] Migrating ceph-osd pool 'volumes' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'volumes' +2024-09-04 09:03.01 [info ] Migrating ceph-osd pool 'images' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'images' +2024-09-04 09:03.01 [info ] Migrating ceph-osd pool 'metrics' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'metrics' +2024-09-04 09:03.01 [info ] Migrating ceph-osd pool 'vms' +2024-09-04 09:03.01 [info ] Migrated ceph-osd pool 'vms' +2024-09-04 09:03.01 [info ] Migrating ceph-rgw daemon at host 'testbed-node-2' +2024-09-04 09:04.27 [info ] Disabled ceph-rgw host 'testbed-node-2' +2024-09-04 09:04.35 [info ] Rook based RGW daemon for node 'testbed-node-2' available +2024-09-04 09:04.35 [info ] Migrating ceph-rgw daemon at host 'testbed-node-1' +2024-09-04 09:04.41 [info ] Disabled ceph-rgw host 'testbed-node-1' +2024-09-04 09:05.09 [info ] Rook based RGW daemon for node 'testbed-node-1' available +2024-09-04 09:05.09 [info ] Migrating ceph-rgw daemon at host 'testbed-node-0' +2024-09-04 09:05.13 [info ] Disabled ceph-rgw host 'testbed-node-0' +2024-09-04 09:05.19 [info ] Rook based RGW daemon for node 'testbed-node-0' available +``` + +Wow! You migrated from Ceph-Ansible to Rook! +Now login into the testbed and check your ceph cluster's health with `ceph -s`. Also use `kubectl` to check if all Rook pods are running.