blogs: update, members: path update

Signed-off-by: Boekhorst <[email protected]>

_i18n/de/_posts/blog/2024-08-26-ceph-rook.md

@@ -7,7 +7,7 @@ author:
 avatar:
 - "rboekhorst.jpg"
 about:
-- "boekhorstb1"
+- "boekhorst"
 ---
 
 ## Ceph-Bereitstellung mit Rook

_i18n/de/_posts/blog/2024-08-27-rookify.md

@@ -7,24 +7,22 @@ author:
 avatar:
 - "rboekhorst.jpg"
 about:
-- "boekhorstb1"
+- "boekhorst"
 ---
 
-## Migration von Ceph-Ansible zu Rook mit Rookify
-
 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
+## Funktionen und Design
 
-#### Statemachine (Zustandsautomat)
+### Statemachine (Zustandsautomat)
 
 Rookify ist ein Python-Paket, das einen Zustandsautomaten-Ansatz verwendet, basierend auf der ['transitions-library'](https://github.com/pytransitions/transitions), 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.yml`-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
+### 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, das den Fortschrittsstatus extern speichert, d.h. welche Module ausgeführt wurden und Informationen über die Zielmaschine. Das beduetet:
 
@@ -33,7 +31,7 @@ Rookify unterstützt optional (empfohlen) die Verwendung einer **Pickle-Datei**
 
 _HINWEIS_: Die Pickle-Datei sollte 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.
 
-Einfache CLI
+### Einfache CLI
 
 Neue Funktionen sind in Entwicklung, welche die bestehende CLI-Oberfläche verbessern. Das cli sollte die Pickle-Datei lesen und die Module von Rookify verwenden können, um den genauen Stand des Migrationsprozesses zu berichten. Das bedeutet, dass Rookify genau dort fortfahren kann, wo eine unterbrochene oder teilweise fehlgeschlagene Migration aufgehört hat.
 
@@ -47,7 +45,7 @@ options:
   --dry-run
 ```
 
-#### Rookifys Arbeitsablauf: Wie wird die Aufgabe erledigt?
+### Rookifys 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.yml`-Datei an:
 
@@ -60,15 +58,10 @@ migration_modules:
 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.0 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.
-
-2.1 `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, wie bei jedem anderen Modul, `analyze_ceph` zuerst im Preflight-Modus läuft, um zu überprüfen, ob der Zustand bereits in der Pickle-Datei erfasst wurde. Wenn kein Zustand gefunden wird, sammelt `analyze_ceph` die notwendigen Informationen.
-
-2.2 Cluster-Erstellung: Nach erfolgreicher Ausführung des `analyze_ceph`-Moduls überprüft Rookify auf weitere Abhängigkeiten, wie das `create_cluster`-Modul. Dieses Modul erstellt die `clustermap.yaml` für Rook basierend auf den Informationen aus `analyze_ceph` und richtet die erforderlichen Namespaces in Kubernetes ein.
-
+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. `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, wie bei jedem anderen Modul, `analyze_ceph` zuerst im Preflight-Modus läuft, um zu überprüfen, ob der Zustand bereits in der Pickle-Datei erfasst wurde. Wenn kein Zustand gefunden wird, sammelt `analyze_ceph` die notwendigen Informationen.
+    2. Cluster-Erstellung: Nach erfolgreicher Ausführung des `analyze_ceph`-Moduls überprüft Rookify auf weitere Abhängigkeiten, wie das `create_cluster`-Modul. Dieses Modul erstellt die `clustermap.yaml` für Rook basierend auf den Informationen aus `analyze_ceph` und richtet die erforderlichen Namespaces in Kubernetes ein.
 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.
@@ -121,7 +114,7 @@ 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
+### Rookify-Einrichtung/Konfiguration für das Testbed von OSISM
 
 1. **Klonen des Rookify-Repositorys**: 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`) Stammverzeichnis des Arbeitsverzeichnisses ausführen. 
 

_i18n/en/_posts/blog/2024-08-26-ceph-rook.md

@@ -7,7 +7,7 @@ author:
 avatar:
 - "rboekhorst.jpg"
 about:
-- "boekhorstb1"
+- "boekhorst"
 ---
 
 ## Ceph Deployment with Rook

_i18n/en/_posts/blog/2024-08-27-rookify.md

@@ -7,18 +7,16 @@ author:
 avatar:
 - "rboekhorst.jpg"
 about:
-- "boekhorstb1"
+- "boekhorst"
 ---
 
-## Migrating from Ceph-Ansible to Rook with Rookify
-
 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
+## Features and Design
 
-#### Statemachine
+### Statemachine
 
-Rookify is a python package that uses a **state-machine approach** 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.
+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.
 
@@ -32,7 +30,7 @@ Rookify optionally (and recommended) supports using a **pickle-file** (see on to
 
 _NOTE_: 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 picklefile should be deleted.
 
-#### A simple CLI
+### A simple CLI
 
 New features are currently in development to enhance the existing CLI interface, allowing it to read the pickle file and use Rookify's modules to report the exact state of the migration process. This means, for example, that Rookify will be able to show from where a discontinued or partially failed migration can be continued. 
 
@@ -46,7 +44,7 @@ options:
   --dry-run
 ```
 
-#### Rookify's general workflow: migrating monitors? 
+### 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.yml` file:
 
@@ -59,15 +57,10 @@ migration_modules:
 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.0 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.
-
-2.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.1 Cluster Creation: After successfully running the analyze-ceph` module, Rookify will check for other dependencies, such as the `create-cluster` module. This module creates the cluster map for Rook based on information from `analyze-ceph` and sets up the necessary namespaces in Kubernetes.
-
+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. Cluster Creation: After successfully running the analyze-ceph` module, Rookify will check for other dependencies, such as the `create-cluster` module. This module creates the cluster map for Rook based on information from `analyze-ceph` and sets up the necessary namespaces in Kubernetes.
 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 skipp this module and only check if it has indeed bin run sucessfully.
 
 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.
@@ -87,9 +80,9 @@ The "one-by-one"-algorithm described for managers and monitors does not work her
 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:
-- 2 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 3 mds instances, only one mds instance will be switched off.
-- now the switched off instances will be given to rook to rebuild them.
-- as soons as Rook has finished and the instances are built, the 2 mds instances under ceph-ansible are switched off as well so rook can rebuild and update them as it likes.
+1. 2 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 3 mds instances, only one mds instance will be switched off.
+2. now the switched off instances will be given to rook to rebuild them.
+3. as soons as Rook has finished and the instances are built, the 2 mds instances under ceph-ansible are switched off as well so rook can rebuild and update them as it likes.
 
 ## Test run: Give it a try and help with testing process
 
@@ -118,7 +111,7 @@ 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
+### 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:
 

_members/boekhorst.md

@@ -1,5 +1,5 @@
 ---
-author_slug: boekhorstb1
+author_slug: boekhorst
 title: Rafael te Boekhorst
 layout: community
 lastname: Boekhorst