pre-commit fixes

Author: fhennig

modules/concepts/pages/container-images.adoc

@@ -38,7 +38,7 @@ See our documentation xref:concepts:multi-platform-support.adoc[on multi-platfor
 [#signatures]
 == Image signatures
 
-All Stackable images are signed. 
+All Stackable images are signed.
 Image signatures help to ensure the authenticity and integrity of container images.
 You can xref:guides:enabling-verification-of-image-signatures.adoc[verify image signatures automatically] in your cluster to make sure that the images you are running are authentic and intact.
 

modules/concepts/pages/index.adoc

@@ -18,7 +18,7 @@ Learn about how to access xref:experimental-arm64-support[ARM64-support].
 
 == Connectivity
 
-Many Platform components depend on other components or expose functionality that you can connect to. 
+Many Platform components depend on other components or expose functionality that you can connect to.
 This connectivity is achived with xref:service-discovery.adoc[service discovery ConfigMaps].
 To access your Stackable operated products from outside the Kuberenetes cluster learn more about xref:service-exposition.adoc[].
 

modules/concepts/pages/logging.adoc

@@ -94,7 +94,7 @@ spec:
                   level: NONE
             sidecar-container:
               console:
-                level: ERROR 
+                level: ERROR
 ----
 <1> The discovery ConfigMap of the Vector aggregator to publish the logs to. This is set at cluster level.
 <2> The role or role group config containing the logging configuration.

modules/concepts/pages/multi-platform-support.adoc

@@ -11,4 +11,4 @@ For example, the Airflow images with tags `airflow:2.9.2-stackable24.7.0-amd64`
 The appropriate image will then be transparently selected for the active platform/architecture.
 This also enables mixed Kubernetes clusters, with AMD64 and ARM64 nodes being used simultaneously.
 
-NOTE: Superset 2.x (deprecated, and to be removed in a future version) is not available as a multi-platform product image.
+NOTE: Superset 2.x (deprecated, and to be removed in a future version) is not available as a multi-platform product image.

modules/concepts/pages/operations/cluster_operations.adoc

@@ -98,7 +98,7 @@ To restart the HDFS DataNode Pods, run:
 
 [source,shell]
 ----
-$ kubectl rollout restart statefulset dumbo-datanode-default 
+$ kubectl rollout restart statefulset dumbo-datanode-default
 statefulset.apps/dumbo-datanode-default restarted
 ----
 

modules/concepts/pages/overview.adoc

@@ -77,4 +77,4 @@ image::common_objects.drawio.svg[]
 
 These objects can be reused by all operators that support this feature. The S3 bucket only needs to be described once, and then it can be referenced in all products that support reading and/or writing from/to S3. Learn more about S3 configuration: xref:s3.adoc[].
 
-Similarly for the OpenPolicyAgent (OPA). Configuring it looks the same across all products. Learn more: xref:opa.adoc[].
+Similarly for the OpenPolicyAgent (OPA). Configuring it looks the same across all products. Learn more: xref:opa.adoc[].

modules/concepts/pages/s3.adoc

@@ -49,7 +49,7 @@ image::s3-overview.drawio.svg[A diagram showing four variations (A, B, C, D) of
 The diagram above shows four examples of how the objects can be structured.
 
 // Variant A
-Variant A shows all S3 objects inlined in a DruidCluster resource. This is a very convenient way to quickly test something since the entire configuration is encapsulated in a single but potentially large manifest. 
+Variant A shows all S3 objects inlined in a DruidCluster resource. This is a very convenient way to quickly test something since the entire configuration is encapsulated in a single but potentially large manifest.
 
 // Variant B
 In variant B the S3 bucket has been split out into its own resource. It can now be referred to by multiple different tools as well.

modules/concepts/pages/stacklet.adoc

@@ -14,7 +14,7 @@ The products are usually deployed with StatefulSets from which Pods are created.
 Configuration is done with ConfigMaps, and the the software is exposed using Services.
 To allow for easier connectivity between Stacklets, some operators also deploy a xref:service-discovery.adoc[] for Stacklets they manage.
 
-CAUTION: Watch out for name collisions when deploying multiple Stacklets in the same namespace! 
+CAUTION: Watch out for name collisions when deploying multiple Stacklets in the same namespace!
 Even though the resource might be different (TrinoCluster, HbaseCluster), there is a name conflict for the discovery ConfigMap if two Stacklets in the same Kubernetes namespace share a name.
 It is best to always use unique names for Stacklets.