Fixed a bunch of refs

Author: fhennig

modules/concepts/pages/opa.adoc

@@ -15,7 +15,7 @@ Policy requests are made to a REST API, which allows easy requests from microser
 
 == How it works
 // How it is deployed
-OPA is run by the xref:opa::index.adoc[Stackable OPA operator]. OPA is deployed with the OpaCluster resource, from which the operator creates a DaemonSet to run an OPA instance on every node of the cluster. Because of this, every Pod making policy requests will always make the request locally, minimizing latency and network traffic.
+OPA is run by the xref:opa:index.adoc[Stackable OPA operator]. OPA is deployed with the OpaCluster resource, from which the operator creates a DaemonSet to run an OPA instance on every node of the cluster. Because of this, every Pod making policy requests will always make the request locally, minimizing latency and network traffic.
 
 === Define policies
 
@@ -79,10 +79,10 @@ The automatic connection is facilitated by the xref:service_discovery.adoc[servi
 
 == Further reading
 
-Read more about the xref:opa::index.adoc[]. Read more about product integration with OPA for these products:
+Read more about the xref:opa:index.adoc[]. Read more about product integration with OPA for these products:
 
-* xref:trino:usage_guide:security.adoc#_authorization[Trino]
-* xref:kafka::usage.adoc[Kafka]
-* xref:druid::usage.adoc#_using_open_policy_agent_opa_for_authorization[Druid]
+* xref:trino:usage_guide/security.adoc#_authorization[Trino]
+* xref:kafka:usage.adoc[Kafka]
+* xref:druid:usage.adoc#_using_open_policy_agent_opa_for_authorization[Druid]
 
 You can also have a look at the xref:contributor:opa_configuration.adoc[implementation guidelines for OPA authorizers] or learn more about the xref:service_discovery.adoc[service discovery mechanism] used across the platform.

modules/concepts/pages/pvc.adoc

@@ -81,10 +81,10 @@ Managed Kubernetes clusters will normally have a default storage implementation
 == Operator usage
 
 === Airflow
-The xref:airflow::index.adoc[Airflow operator] can use a xref:airflow::usage.adoc#_via_persistentvolumeclaim[PersistentVolumeClaim for externally-loaded airflow jobs], known as Direct Acyclic Graphs (DAGs), as shown in this https://github.com/stackabletech/airflow-operator/blob/main/examples/simple-airflow-cluster-dags-pvc.yaml[example]. Airflow expects that all components (webserver, scheduler and workers) have access to the DAG folder, so the PersistentVolumeClaim either has to be accessible with the `ReadWriteMany` access mode or node selection should be declared to ensure all components run on the same node.
+The xref:airflow:index.adoc[Airflow operator] can use a xref:airflow:usage.adoc#_via_persistentvolumeclaim[PersistentVolumeClaim for externally-loaded airflow jobs], known as Direct Acyclic Graphs (DAGs), as shown in this https://github.com/stackabletech/airflow-operator/blob/main/examples/simple-airflow-cluster-dags-pvc.yaml[example]. Airflow expects that all components (webserver, scheduler and workers) have access to the DAG folder, so the PersistentVolumeClaim either has to be accessible with the `ReadWriteMany` access mode or node selection should be declared to ensure all components run on the same node.
 
 === Spark-k8s
-Users of the xref:spark-k8s::index.adoc[Spark-k8s operator] have a variety of ways to manage SparkApplication dependencies, one of which is to xref:spark-k8s::usage.adoc#_pyspark_externally_located_dataset_artifact_available_via_pvcvolume_mount[mount resources on a PersistentVolumeClaim]. An example is shown https://github.com/stackabletech/spark-k8s-operator/blob/main/examples/ny-tlc-report.yaml[here].
+Users of the xref:spark-k8s:index.adoc[Spark-k8s operator] have a variety of ways to manage SparkApplication dependencies, one of which is to xref:spark-k8s:usage.adoc#_pyspark_externally_located_dataset_artifact_available_via_pvcvolume_mount[mount resources on a PersistentVolumeClaim]. An example is shown https://github.com/stackabletech/spark-k8s-operator/blob/main/examples/ny-tlc-report.yaml[here].
 
 == Further reading
 

modules/concepts/pages/s3.adoc

@@ -3,7 +3,7 @@
 // -------------- Intro ----------------
 
 Many of the tools on the Stackable platform integrate with S3 storage in some way.
-For example Druid can xref:druid::usage.adoc#_s3_for_ingestion[ingest data from S3] and also xref:druid::usage.adoc##_s3_deep_storage[use S3 as a backend for deep storage], Spark can use an xref:spark-k8s::usage.adoc#_s3_bucket_specification[S3 bucket] to store application files and data.
+For example Druid can xref:druid:usage.adoc#_s3_for_ingestion[ingest data from S3] and also xref:druid:usage.adoc##_s3_deep_storage[use S3 as a backend for deep storage], Spark can use an xref:spark-k8s:usage.adoc#_s3_bucket_specification[S3 bucket] to store application files and data.
 
 == S3Connection and S3Bucket
 // introducing the objects

modules/concepts/pages/service_discovery.adoc

@@ -37,7 +37,7 @@ data:
   ZOOKEEPER: simple-zk-server-default-0.simple-zk-server-default.default.svc.cluster.local:2181,simple-zk-server-default-1.simple-zk-server-default.default.svc.cluster.local:2181
 ----
 
-The information needed to connect can be a string like above, for example a JDBC connect string: `jdbc:postgresql://localhost:12345`. But a ConfigMap can also contain multiple configuration files which can then be mounted into a client Pod. This is the case for xref:hdfs::discovery.adoc[HDFS], where the `core-site.xml` and `hdfs-site.xml` files are put into the discovery ConfigMap.
+The information needed to connect can be a string like above, for example a JDBC connect string: `jdbc:postgresql://localhost:12345`. But a ConfigMap can also contain multiple configuration files which can then be mounted into a client Pod. This is the case for xref:hdfs:discovery.adoc[HDFS], where the `core-site.xml` and `hdfs-site.xml` files are put into the discovery ConfigMap.
 
 == Usage of the service discovery ConfigMap
 
@@ -79,7 +79,7 @@ In general, use the name of the product instance to retrieve the ConfigMap and u
 
 === Discovering services outside Stackable
 
-It is not uncommon to already have some core software running in your stack, such as HDFS. If you want to use HBase with the Stackable operator, you can still connect your already existing HDFS instance. You will have to create the discovery ConfigMap for your already existing HDFS yourself. Looking at xref:hdfs::discovery.adoc[the discovery documentation for HDFS], you can see that the discovery ConfigMap for HDFS contains the `core-site.xml` and `hdfs-site.xml` files.
+It is not uncommon to already have some core software running in your stack, such as HDFS. If you want to use HBase with the Stackable operator, you can still connect your already existing HDFS instance. You will have to create the discovery ConfigMap for your already existing HDFS yourself. Looking at xref:hdfs:discovery.adoc[the discovery documentation for HDFS], you can see that the discovery ConfigMap for HDFS contains the `core-site.xml` and `hdfs-site.xml` files.
 
 The ConfigMap should look something like this:
 
@@ -114,9 +114,9 @@ spec:
 
 Consult discovery ConfigMap documentation for specific products:
 
-* xref:druid::discovery.adoc[Apache Druid]
-* xref:hdfs::discovery.adoc[Apache Hadoop HDFS]
-* xref:hive::discovery.adoc[Apache Hive]
-* xref:kafka::discovery.adoc[Apache Kafka]
-* xref:opa::discovery.adoc[OPA]
-* xref:zookeeper::discovery.adoc[Apache ZooKeeper]
+* xref:druid:discovery.adoc[Apache Druid]
+* xref:hdfs:discovery.adoc[Apache Hadoop HDFS]
+* xref:hive:discovery.adoc[Apache Hive]
+* xref:kafka:discovery.adoc[Apache Kafka]
+* xref:opa:discovery.adoc[OPA]
+* xref:zookeeper:discovery.adoc[Apache ZooKeeper]

modules/concepts/pages/tls_server_verification.adoc

@@ -37,7 +37,7 @@ include::example$tls-server-verification-webpki.yaml[]
 ----
 
 This example will use TLS and verify the server using the provided ca certificate.
-For this to work you need to create a xref:secret-operator::secretclass.adoc[] that - at least - contains the ca certificate.
+For this to work you need to create a xref:secret-operator:secretclass.adoc[] that - at least - contains the ca certificate.
 Note that a SecretClass does not need to have a key but can also work with just a ca cert.
 So if you were provided with a ca cert but do not have access to the key you can still use this method.
 
@@ -48,8 +48,8 @@ include::example$tls-server-verification-custom-ca.yaml[]
 
 === Mutual verification
 This example will use TLS and verify both - the server and the client using certificates.
-For this to work you need to create a xref:secret-operator::secretclass.adoc[] containing the ca certificate and a key to create new client-certificates.
-The xref:secret-operator::index.adoc[] will automatically provide the product with a `ca.crt`, `tls.crt` and `tls.key` so that the product can authenticate the server and it can authenticate itself at the server.
+For this to work you need to create a xref:secret-operator:secretclass.adoc[] containing the ca certificate and a key to create new client-certificates.
+The xref:secret-operator:index.adoc[] will automatically provide the product with a `ca.crt`, `tls.crt` and `tls.key` so that the product can authenticate the server and it can authenticate itself at the server.
 
 [source,yaml]
 ----

modules/reference/pages/authenticationclass.adoc

@@ -15,8 +15,8 @@ include::example$authenticationclass-ldap-full.yaml[]
 <3> The searchBase where the users should be searched
 <4> Additional filter that filters the allowed users
 <5> The name of the corresponding field names in the LDAP objects
-<6> The name of the xref:secret-operator::secretclass.adoc[] providing the bind credentials (username and password)
-<7> The xref:secret-operator::scope.adoc[] of the xref:secret-operator::secretclass.adoc[]
+<6> The name of the xref:secret-operator:secretclass.adoc[] providing the bind credentials (username and password)
+<7> The xref:secret-operator:scope.adoc[] of the xref:secret-operator:secretclass.adoc[]
 <8> xref:concepts:tls_server_verification.adoc[] of the LDAP server
 
 To learn more, you can follow the xref:tutorials:authentication_with_openldap.adoc[] tutorial.

modules/tutorials/pages/authentication_with_openldap.adoc

@@ -91,8 +91,8 @@ Notice the SecretClass annotation. Create the SecretClass next:
 [source,yaml]
 include::example$ldap-auth/bind-credentials-secretclass.yaml[]
 
-<1> The name of the xref:secret-operator::secretclass.adoc[] we are creating that is referred to by the Secret
-<2> This determines the namespace in which the referenced `Secret` will be looked for. In this case it searches for a `Secret` in the same namespace as the product runs in. See xref:secret-operator::secretclass.adoc#backend-k8ssearch[the documentation of SecretClass]
+<1> The name of the xref:secret-operator:secretclass.adoc[] we are creating that is referred to by the Secret
+<2> This determines the namespace in which the referenced `Secret` will be looked for. In this case it searches for a `Secret` in the same namespace as the product runs in. See xref:secret-operator:secretclass.adoc#backend-k8ssearch[the documentation of SecretClass]
 
 // [source,bash]
 // include::example$ldap-auth/30-install-openldap.sh[tag=apply-credentials-secretclass]
@@ -288,7 +288,7 @@ Again, like with Superset, connect to Trino now (make sure that the StatefulSets
 
 This is a bonus step, and if you want you can skip straight to the next section: <<trino_try_it>>
 
-This step is not required for _authentication_ by itself. But the demo stack you installed comes with an _authorization_ configuration for Trino as well. Authorization on the platform is done using the xref:opa::index.adoc[].
+This step is not required for _authentication_ by itself. But the demo stack you installed comes with an _authorization_ configuration for Trino as well. Authorization on the platform is done using the xref:opa:index.adoc[].
 
 Fetch the snippet as before:
 
@@ -335,6 +335,6 @@ The LDAP connection details only need to be written down once, in the Authentica
 
 - xref:concepts:authentication.adoc[Authentication concepts page]
 - xref:reference:authenticationclass.adoc[AuthenticationClass reference]
-- xref:superset:getting_started:index.adoc[Getting started with the Stackable Operator for Apache Superset]
-- xref:trino:getting_started:index.adoc[Getting started with the Stackable Operator for Trino]
+- xref:superset:getting_started/index.adoc[Getting started with the Stackable Operator for Apache Superset]
+- xref:trino:getting_started/index.adoc[Getting started with the Stackable Operator for Trino]
 // TODO Operator docs for LDAP