datastax · aimurphy · Apr 1, 2026 · Mar 31, 2026 · Mar 31, 2026
diff --git a/antora.yml b/antora.yml
@@ -18,8 +18,4 @@ asciidoc:
     pulsar-reg: 'Apache Pulsar(TM)'
     starlight-kafka: 'Starlight for Kafka'
     kafka-reg: 'Apache Kafka(R)'
-    kafka-short: 'Kafka'
-    cr: 'custom resource (CR)'
-    cr-short: 'CR'
-    crd: 'custom resource definition (CRD)'
-    crd-short: 'CRD'
+    kafka-short: 'Kafka'
diff --git a/local-preview-playbook.yml b/local-preview-playbook.yml
@@ -66,7 +66,7 @@ asciidoc:
     astra-ui: 'Astra Portal'
     astra-url: 'https://astra.datastax.com'
     astra-ui-link: '{astra-url}[{astra-ui}^]'
-    db-classic: 'Managed Cluster'
+    db-classic: 'Astra Managed Clusters'
     db-serverless: 'Serverless (non-vector)'
     db-serverless-vector: 'Serverless (vector)'
     scb: 'Secure Connect Bundle (SCB)'
@@ -78,7 +78,6 @@ asciidoc:
     astra-stream: 'Astra Streaming'
     starlight-kafka: 'Starlight for Kafka'
     starlight-rabbitmq: 'Starlight for RabbitMQ'
-    astra-streaming-examples-repo: 'https://github.com/datastax/astra-streaming-examples'
     sstable-sideloader: '{astra-db} Sideloader'
     zdm: 'Zero Downtime Migration'
     zdm-short: 'ZDM'
@@ -217,10 +216,6 @@ asciidoc:
     capacity-service: 'Capacity Service'
     lcm: 'Lifecycle Manager (LCM)'
     lcm-short: 'LCM'
-    cr: 'custom resource (CR)'
-    cr-short: 'CR'
-    crd: 'custom resource definition (CRD)'
-    crd-short: 'CRD'
     # Antora Atlas
     primary-site-url: https://docs.datastax.com/en
     primary-site-manifest-url: https://docs.datastax.com/en/site-manifest.json

diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc
@@ -26,7 +26,7 @@
 * xref:resource-sets:proxies.adoc[]
 * xref:resource-sets:racks.adoc[]
 
-.{crd-short} spec
+.CRD spec
 * xref:crd-spec:Autorecovery.openapi.adoc[]
 * xref:crd-spec:Bastion.openapi.adoc[]
 * xref:crd-spec:BookKeeper.openapi.adoc[]

diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc
@@ -15,7 +15,7 @@ Some of the key features and benefits of the {product-short} include:
 
 - **Lifecycle Management**: The operator takes care of common {pulsar-short} cluster lifecycle tasks, such as cluster creation, upgrade, configuration updates, and graceful shutdowns.
 
-We also offer the xref:getting-started:stack.adoc[{pulsar-stack}] if you're looking for more Kubernetes-native tooling deployed with your {pulsar-short} cluster. Along with the `PulsarCluster` {crd}, {pulsar-stack} also includes:
+We also offer the xref:getting-started:stack.adoc[{pulsar-stack}] if you're looking for more Kubernetes-native tooling deployed with your {pulsar-short} cluster. Along with the `PulsarCluster` custom resource definition (CRD), {pulsar-stack} also includes:
 
 * {product-short}
 * Prometheus Stack (Grafana)
@@ -30,7 +30,7 @@ We will cover installation and deployment, configuration points, and further opt
 
 == Features
 
-After a new {cr} type is added to your cluster by installing a {crd-short}, you can create instances of the resource based on its specification.
+After a new custom resource (CR) type is added to your cluster by installing a CRD, you can create instances of the resource based on its specification.
 The Kubernetes API can be extended to support the new resource type, automating away the tedious aspects of managing a {pulsar-short} cluster.
 
 * xref:scaling-components:autoscale-bookies.adoc[BookKeeper autoscaler] - Automatically scale the number of bookies based on memory usage.
@@ -42,7 +42,7 @@ The Kubernetes API can be extended to support the new resource type, automating
 
 Operators are a common pattern for packaging, deploying, and managing Kubernetes applications.
 Operators extend Kubernetes functionality to automate common tasks in stateful applications.
-Think of {product-short} as a manager for the individual components of {pulsar-short}. By implementing the `PulsarCluster` {crd-short}, the operator knows enough to manage the deployment, configuration, and scaling of {pulsar-short} components with re-usable and automated tasks, such as:
+Think of {product-short} as a manager for the individual components of {pulsar-short}. By implementing the `PulsarCluster` CRD, the operator knows enough to manage the deployment, configuration, and scaling of {pulsar-short} components with re-usable and automated tasks, such as:
 
 * Deploying a {pulsar-short} cluster
 * Deploying monitoring and logging components
@@ -76,13 +76,13 @@ In addition to the required components, you might want to include some *optional
 
 {product-short} can be installed in two ways.
 
-* xref:getting-started:operator.adoc[{product-short}] - Installs just the operator and the `PulsarCluster` {crd-short} into an existing {pulsar-short} cluster.
+* xref:getting-started:operator.adoc[{product-short}] - Installs just the operator and the `PulsarCluster` CRD into an existing {pulsar-short} cluster.
 
 * xref:getting-started:stack.adoc[{pulsar-stack}] - Installs and deploys the operator, a {pulsar-short} cluster, and a full Prometheus monitoring stack.
 
 [TIP]
 ====
-You can also scan an existing {pulsar-short} cluster and generate an equivalent `PulsarCluster` {crd-short}. For more, see xref:migration:migrate-cluster.adoc[].
+You can also scan an existing {pulsar-short} cluster and generate an equivalent `PulsarCluster` CRD. For more, see xref:migration:migrate-cluster.adoc[].
 ====
 
 To get started, see xref:getting-started:index.adoc[Getting Started].

diff --git a/modules/getting-started/pages/index.adoc b/modules/getting-started/pages/index.adoc
@@ -2,11 +2,11 @@
 
 {product-short} can be installed in two ways.
 
-* xref:getting-started:operator.adoc[{product-short}] - Installs just the operator pod and the `PulsarCluster` {crd}.
+* xref:getting-started:operator.adoc[{product-short}] - Installs just the operator pod and the `PulsarCluster` custom resource definition (CRD).
 
 * xref:getting-started:stack.adoc[{pulsar-stack}] - Installs and deploys the operator, a {pulsar-short} cluster, and a full Prometheus monitoring stack.
 
 [TIP]
 ====
-If you have an existing {pulsar-short} cluster, you can scan and generate an equivalent `PulsarCluster` {crd-short}. For more, see xref:migration:migrate-cluster.adoc[].
+If you have an existing {pulsar-short} cluster, you can scan and generate an equivalent `PulsarCluster` CRD. For more, see xref:migration:migrate-cluster.adoc[].
 ====
diff --git a/modules/getting-started/pages/operator.adoc b/modules/getting-started/pages/operator.adoc
@@ -1,7 +1,7 @@
 = Install {product-short} Helm chart
 
 {product-short} is installed using Helm.
-You can install just the operator and the `PulsarCluster` {crd}, or you can install xref:stack.adoc[{pulsar-stack}], which includes the operator, {crd-short}, and the Prometheus monitoring stack.
+You can install just the operator and the `PulsarCluster` custom resource definition (CRD), or you can install xref:stack.adoc[{pulsar-stack}], which includes the operator, CRD, and the Prometheus monitoring stack.
 
 [#operator]
 == Install {product-short}
@@ -114,10 +114,10 @@ Events:
 +
 You've now installed KAAP.
 +
-By default, when KAAP is installed, the `PulsarCluster` {crd-short}s are also created.
+By default, when KAAP is installed, the `PulsarCluster` CRDs are also created.
 This setting is defined in the {product-short} values.yaml file as `crd: create: true`.
 
-. Get the available {crd-short}s:
+. Get the available CRDs:
 +
 [source,shell]
 ----

diff --git a/modules/getting-started/pages/upgrades.adoc b/modules/getting-started/pages/upgrades.adoc
@@ -3,7 +3,7 @@
 The {product-short} performs cluster upgrades in a very conservative manner, with the primary goal of reducing maintenance time during upgrades.
 Components are updated and then restarted *only* if strictly needed.
 For example, if only the broker needs to be upgraded, then all other services will be left up and running.
-If there is an error or interruption during upgrade, the operator will apply the desired state defined in the `PulsarCluster` {cr} until the resource matches the actual state.
+If there is an error or interruption during upgrade, the operator will apply the desired state defined in the `PulsarCluster` custom resource (CR) until the resource matches the actual state.
 
 == Upgrade schema
 
@@ -125,9 +125,9 @@ pulsar-cluster   pulsar-zookeeper-metadata-zgfn4                            0/1
 
 You've successfully upgraded your deployment by changing only one YAML file.
 
-== Upgrade {crd-short}s
+== Upgrade CRDs
 
-To upgrade {crd-short}s, run the following command:
+To upgrade CRDs, run the following command:
 
 [source,shell]
 ----

diff --git a/modules/migration/pages/migrate-cluster.adoc b/modules/migration/pages/migrate-cluster.adoc
@@ -2,7 +2,7 @@
 
 Migrating an existing {pulsar-reg} cluster to one controlled by the {product-short} is a manual process, but we've included a migration tool to help you along the way.
 
-The migration tool is a CLI application that connects to an existing {pulsar} cluster and generates a valid and equivalent `PulsarCluster` {crd}.
+The migration tool is a CLI application that connects to an existing {pulsar} cluster and generates a valid and equivalent `PulsarCluster` custom resource definition (CRD).
 The migration tool simulates what would happen if the generated `PulsarCluster` would be submitted, retrieves the Kubernetes resources that would be created, and compares them with the existing cluster's resources, generating a detailed HTML report.
 You can then examine the report and decide if you want to proceed with the cluster migration, or if you need to make some changes first.
 
@@ -11,7 +11,7 @@ You can then examine the report and decide if you want to proceed with the clust
 * An existing {pulsar} cluster
 * Migration-tool JAR downloaded from the https://github.com/datastax/kaap/releases[latest release].
 
-== Scan and generate cluster {crd-short}s
+== Scan and generate cluster CRDs
 
 . Create an input file called `input-cluster-specs.yaml` with the following content:
 +
@@ -57,7 +57,7 @@ java -jar migration-tool.jar generate -i input-cluster-specs.yaml -o output
 +
 If everything looks good, proceed to the <<migration-procedure,migration procedure>>.
 +
-If you need to change the generated {crd-short} and simulate the migration again, run the following command after making the necessary changes:
+If you need to change the generated CRD and simulate the migration again, run the following command after making the necessary changes:
 +
 [source,java]
 ----
@@ -69,7 +69,7 @@ java -jar migration-tool.jar diff -d output/<context-name>
 
 . Create a new `values.yaml` file for the operator.
 
-. In the `pulsar-operator.cluster` section, enter the generated {crd-short} spec.
+. In the `pulsar-operator.cluster` section, enter the generated CRD spec.
 +
 [source,yaml]
 ----

diff --git a/modules/scaling-components/pages/index.adoc b/modules/scaling-components/pages/index.adoc
@@ -1,6 +1,6 @@
 = Scaling components
 
-After a new {cr} type is added to your cluster by installing a {crd}, you can create instances of the resource based on its specification.
+After a new custom resource (CR) type is added to your cluster by installing a custom resource definition (CRD), you can create instances of the resource based on its specification.
 The Kubernetes API can be extended to support the new resource type, automating away the tedious aspects of managing a {pulsar-short} cluster.
 
 * xref:scaling-components:autoscale-bookies.adoc[BookKeeper autoscaler] - Automatically scale the number of bookies based on memory usage.