Merge branch 'main' into nomaxscale

docs/infrastructure-mariadb-ops.md

@@ -7,9 +7,9 @@ Tips and tricks for managing and operating the MariaDB cluster within a Genestac
 Sometimes an operator may need to connect to the database to troubleshoot things or otherwise make modifications to the databases in place. The following command can be used to connect to the database from a node within the cluster.
 
 ``` shell
-mysql -h $(kubectl -n openstack get service maxscale-galera -o jsonpath='{.spec.clusterIP}') \
-      -p$(kubectl --namespace openstack get secret maxscale -o jsonpath='{.data.password}' | base64 -d) \
-      -u maxscale-galera-client
+mysql -h $(kubectl -n openstack get service mariadb-galera-primary -o jsonpath='{.spec.clusterIP}') \
+      -p$(kubectl --namespace openstack get secret mariadb -o jsonpath='{.data.root-password}' | base64 -d) \
+      -u root
 ```
 
 !!! info
@@ -92,25 +92,3 @@ for more information.
     If you have multiple backups available, the operator is able to infer which
     backup to restore based on the `spec.targetRecoveryTime` field discussed
     in the operator documentation [here](https://github.com/mariadb-operator/mariadb-operator/blob/main/docs/BACKUP.md#target-recovery-time).
-
-## Interacting with the MaxScale REST API
-
-Refer to the API reference for MaxScale [here](https://mariadb.com/kb/en/mariadb-maxscale-23-08-rest-api/).
-
-!!! info "Example curl request"
-
-    ``` shell
-    curl -s -u mariadb-operator:$(kubectl get secret -n openstack maxscale -o jsonpath='{.data.password}' | base64 -d) http://maxscale-galera.openstack.svc.cluster.local:8989/v1/ -D -
-    ```
-    ``` shell
-    HTTP/1.1 200 OK
-    Connection: close
-    ETag: "da39a3ee5e6b4b0d3255bfef95601890afd80709"
-    Last-Modified: Tue, 30 Apr 2024 20:10:22 GMT
-    Date: Tue, 30 Apr 24 20:44:17 GMT
-    X-Frame-Options: Deny
-    X-XSS-Protection: 1
-    Referrer-Policy: same-origin
-    Cache-Control: no-cache
-    Content-Length: 0
-    ```

docs/infrastructure-mariadb.md

@@ -9,12 +9,6 @@ kubectl --namespace openstack \
         --type Opaque \
         --from-literal=root-password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \
         --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)"
-
-# MaxScale
-kubectl --namespace openstack \
-        create secret generic maxscale \
-        --type Opaque \
-        --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)"
 ```
 
 ## Deploy the mariadb operator
@@ -50,19 +44,3 @@ kubectl --namespace openstack apply -k /opt/genestack/kustomize/mariadb-cluster/
 ``` shell
 kubectl --namespace openstack get mariadbs -w
 ```
-
-## MaxScale
-
-Within the deployment the OpenStack services use MaxScale for loadlancing and greater reliability. While the MaxScale ecosystem is a good one, there are some limitations that you should be aware of. It is recommended that you review the [MaxScale reference documentation](https://mariadb.com/kb/en/mariadb-maxscale-2302-limitations-and-known-issues-within-mariadb-maxscale) for more about all of the known limitations and potential workarounds available.
-
-``` mermaid
-flowchart TD
-    A[Connection] ---B{MaxScale}
-    B ---|ro| C[ES-0]
-    B ---|rw| D[ES-1] ---|sync| E & C
-    B ---|ro| E[ES-2]
-```
-
-### MaxScale GUI
-
-The MaxScale deployment has access to a built in GUI that can be exposed for further debuging and visibility into the performance of the MariDB backend. For more information on accessing the GUI please refer to the MaxScale documentation that can be found [here](https://mariadb.com/resources/blog/getting-started-with-the-mariadb-maxscale-gui).

docs/openstack-servers.md

@@ -53,6 +53,31 @@ openstack server create
     <server-name>
 ```
 
+#### Creating a Server with User Data
+
+You can place user data in a local file and pass it through the --user-data <user-data-file> parameter at instance creation.
+
+``` shell
+openstack server create --image ubuntu-cloudimage --flavor 1 \
+    --user-data mydata.file VM_INSTANCE
+```
+
+#### Creating a Server with Config drives
+
+Config drives are special drives that are attached to an instance when it boots. The instance can mount this drive and read files from it to get information that is normally available through the metadata service.
+
+To enable the config drive for an instance, pass the --config-drive true parameter to the openstack server create command.
+
+The following example enables the config drive and passes a user data file and two key/value metadata pairs, all of which are accessible from the config drive:
+
+``` shell
+openstack server create --config-drive true --image my-image-name \
+    --flavor 1 --key-name mykey --user-data ./my-user-data.txt \
+    --property role=webservers --property essential=false MYINSTANCE
+```
+
+Read more about Openstack Config drives using the [upstream docs](https://docs.openstack.org/nova/latest/admin/config-drive.html).
+
 #### Delete a server
 
 ``` shell

docs/openstack-skyline.md

@@ -17,7 +17,7 @@ kubectl --namespace openstack \
         --from-literal=service-domain="service" \
         --from-literal=service-project="service" \
         --from-literal=service-project-domain="service" \
-        --from-literal=db-endpoint="maxscale-galera.openstack.svc.cluster.local" \
+        --from-literal=db-endpoint="mariadb-galera-primary.openstack.svc.cluster.local" \
         --from-literal=db-name="skyline" \
         --from-literal=db-username="skyline" \
         --from-literal=db-password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \