Minor docs update (#1361)

- Update grafana dashboard install
- Add operational procedure for migrating to galera replication mode

Author: bjoernt

docs/import-grafana-dashboard.md

@@ -31,8 +31,9 @@ options:
                         Name of the Prometheus datasource. Default: "Prometheus"
 
 export GRAFANA_USERNAME=admin
-export GRAFANA_URL=https://grafana.sjc3.rackspacecloud.com
-export GRAFANA_PASSWORD=your_admin_password
+export GRAFANA_URL=`awk -F': ' '/custom_host/{print "https://" $2}' /etc/genestack/helm-configs/grafana/grafana-helm-overrides.yaml`
+export GRAFANA_PASSWORD=`kubectl -n grafana get secret grafana -o jsonpath='{.data.admin-password}' |base64 -d`
 
-python import_dashboards.py --dir /opt/genestack/etc/grafana-dashboards/ --datasource Prometheus
+source /opt/genestack/scripts/genestack.rc
+python3 /opt/genestack/scripts/import-grafana-dashboard.py --dir /opt/genestack/etc/grafana-dashboards/ --datasource Prometheus
 ```

docs/infrastructure-mariadb-ops.md

@@ -158,7 +158,7 @@ for more information.
     maria-restore   True       Success   mariadb-cluster   26s
     ```
 
-## Fixing Replication
+## Fixing Master-Slave Replication
 
 The MariaDB Operator can handle most cluster issues automatically, but
 sometimes you’ll need to roll up your sleeves and step in to fix things.
@@ -256,3 +256,47 @@ Identify master log file and position from the backup file:
     2025-01-28 22:22:55 64 [Note] Master 'mariadb-operator': Slave SQL thread initialized, starting replication in log 'FIRST' at position 4, relay log './mariadb-cluster-relay-bin-mariadb@002doperator.000001' position: 4; GTID position '0-11-638858622'
     2025-01-28 22:22:55 63 [Note] Master 'mariadb-operator': Slave I/O thread: connected to master 'repl@mariadb-cluster-1.mariadb-cluster-internal.openstack.svc.cluster.local:3306',replication starts at GTID position '0-11-638858622'
     ```
+
+## Switching from master/slave replication to galera replication mode
+
+In case the mariadb cluster was originially setup using master/slave
+replication, a switch to galera replication is only possible with a fresh bootstrapped cluster.
+The procedure below will rebuild the entire database and restore the database from
+the most recent backup.
+
+!!! warning
+    Please ensure that you create a database backup before deleting the cluster
+    and that your mariadb operator is running with the version 0.38.1 and higher [see pr #1250](https://github.com/rackerlabs/genestack/pull/1250),
+    before switching the replication mode. Otherwise no automatic failover will work for the galera cluster.
+
+    Check the operator versions with
+    ``` shell
+    kubectl -n mariadb-system get pods -o="custom-columns=NAME:.spec.containers[0].name,IMAGE:.spec.containers[0].image"
+    ```
+
+``` shell
+# Delete the database and persistent volumes
+kubectl -n openstack delete mariadb/mariadb-cluster
+kubectl -n openstack delete pvc -l app.kubernetes.io/instance=mariadb-cluster
+
+# Rebuild the cluster with galera replication
+kubectl -n openstack apply -k /etc/genestack/kustomize/mariadb-cluster/galera
+
+kubectl -n openstack wait mariadb mariadb-cluster --for=condition=Ready
+
+# Restore the database from the last backup
+kubectl -n openstack apply -f - <<EOT
+apiVersion: k8s.mariadb.com/v1alpha1
+kind: Restore
+metadata:
+  name: restore-mariadb
+spec:
+  mariaDbRef:
+    name: mariadb-cluster
+  backupRef:
+    name: mariadb-backup
+EOT
+
+# Delete the restore job
+kubectl -n openstack delete restore/restore-mariadb
+```