fix: typos, naming, links

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

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

@@ -16,9 +16,9 @@ Um den Übergang von Ceph-Ansible zu Rook zu erleichtern, hat SCS ein Migrations
 
 ### 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.
+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.
+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`).
 
@@ -57,19 +57,19 @@ 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. 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.
+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. `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_rook_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.
 
 
 ### Migration von OSDs
 
-Hier funktioniert der für Manager und Monitore beschriebene „Eins-nach-dem-anderen“-Algorithmus nicht, da Rook einen Container namens `prepare_osd` 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 `use_all_nodes=false` und `use_all_devices=false`. Beide Variablen sind standardmäßig in der Rook-Bereitstellung von OSISM auf „false“ gesetzt, dennoch versucht `prepare_osd`, 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. Dies kann wie folgt verhindert werden:
+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. Dies kann wie folgt verhindert werden:
 
 1. Alle OSD-Daemons 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.
@@ -137,7 +137,7 @@ make vpn-sshuttle
 make vpn-wireguard
 ```
 
-3. **Rookify ausführen**: Jezt 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 sie tatsächlich ausgeführt werden. Außerdem machen Sie nichts kaput, wenn Sie die `example`- oder `analyze_ceph`-Module auszuführen, da diese keine kritischen Änderungen vornehmen.
+3. **Rookify ausführen**: Jezt 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 sie tatsächlich ausgeführt werden. Außerdem machen Sie nichts kaput, wenn Sie die `example` oder `analyze_ceph` Module auszuführen, da diese keine kritischen Änderungen vornehmen.
 
 ```yaml
 general:

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

@@ -18,14 +18,14 @@ To facilitate the transition from Ceph-Ansible to Rook, SCS has almost finished
 
 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.
+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.yml` 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 'save' its progress:
-- if a running migration is for some reason stopped, Rookify can use the pickefile to continue from the saved state
+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 pickefile to continue from the saved state.
 - if a migration is run in parts (e.g. modules are run incrementaly), then the pickelfile allows Rookify to save the state of the cluster, i.e. the migration.
 
 _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.
@@ -59,18 +59,18 @@ 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. 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.
+    2. Cluster Creation: After successfully running the analyze-ceph` module, Rookify will check for other dependencies, such as the `create_rook_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.
 
 ### Migrating OSDs
 
-Here the "one-by-one"-algorithm described for managers and monitors does not work, because Rook has a container called `prepare_osd` 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 `use_all_nodes=false` und `use_all_devices=false`. Both variables are set to false per default in the rook deployment of OSISM, nevertheless `prepare_osds` tries to scan and process all osds per node. This means in effect, that a `device is busy`-error will occure as well as a crashloopfeedback. This can be mitigated like so:
+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 occure as well as a crashloop-feedback. This can be mitigated like so:
 
 1. all OSD daemons have to switched of at once
-2. paths of osd devices have to be fed one by to `prepare_osd` to enforce sequential processing
+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