diff --git a/content/u/blog/2022-08-27-migrating-ceph-nautilus-into-kubernetes-with-rook/contents.lr b/content/u/blog/2022-08-27-migrating-ceph-nautilus-into-kubernetes-with-rook/contents.lr
index dfda8ac..1b30a47 100644
--- a/content/u/blog/2022-08-27-migrating-ceph-nautilus-into-kubernetes-with-rook/contents.lr
+++ b/content/u/blog/2022-08-27-migrating-ceph-nautilus-into-kubernetes-with-rook/contents.lr
@@ -424,6 +424,7 @@ For migrating, we don't want rook in the first stage to create any
 OSDs. So we will replace `useAllNodes: true` with `useAllNodes: false`
 and `useAllDevices: true` also with `useAllDevices: false`.
 
+
 ### Extracting a monmap
 
 To get access to the existing monmap, we can export it from the native
@@ -459,6 +460,71 @@ In this particular cluster we have 2 pools:
 The device class "hdd-big" is specific to this cluster as it used to
 contain 2.5" and 3.5" HDDs in different pools.
 
+### [old] Analysing the ceph cluster configuration
+
+Taking the view from the old cluster, the following items are
+important for adding new services/nodes:
+
+* We have a specific fsid that needs to be known
+ * The expectation would be to find that fsid in a configmap/secret in rook
+* We have a list of running monitors
+ * This is part of the monmap and ceph.conf
+ * ceph.conf is used for finding the initial contact point
+ * Afterwards the information is provided by the monitors
+ * For rook it would be expected to have a configmap/secret listing
+   the current monitors
+* The native clusters have a "ceph.client.admin.keyring" deployed which
+allows adding and removing resources.
+ * Rook probably has a secret for keyrings
+ * Maybe multiple depending on how services are organised
+
+### Analysing the rook configurations
+
+Taking the opposite view, we can also checkout a running rook cluster
+
+### Configuring ceph after the operator deployment
+
+As soon as the operator and the crds have been deployed, we deploy the
+following
+[CephCluster](https://rook.io/docs/rook/v1.8/ceph-cluster-crd.html)
+configuration:
+
+```
+apiVersion: ceph.rook.io/v1
+kind: CephCluster
+metadata:
+  name: rook-ceph
+  namespace: rook-ceph
+spec:
+  cephVersion:
+    image: quay.io/ceph/ceph:v14.2.21
+  dataDirHostPath: /var/lib/rook
+  mon:
+    count: 5
+    allowMultiplePerNode: false
+  storage:
+    useAllNodes: false
+    useAllDevices: false
+    onlyApplyOSDPlacement: false
+  mgr:
+    count: 1
+    modules:
+      - name: pg_autoscaler
+        enabled: true
+  network:
+    ipFamily: "IPv6"
+    dualStack: false
+  crashCollector:
+    disable: false
+    # Uncomment daysToRetain to prune ceph crash entries older than the
+    # specified number of days.
+    daysToRetain: 30
+```
+
+We wait for the cluster to initialise and stabilise before applying
+changes. Important to note is that we use the ceph image version
+v14.2.21, which is the same version as the native cluster.
+
 
 
 ## Changelog
@@ -466,6 +532,7 @@ contain 2.5" and 3.5" HDDs in different pools.
 ### 2022-09-03
 
 * Next try starting for migration
+* Looking deeper into configurations
 
 ### 2022-08-29