module segment in xrefs (#180)

aimurphy · web-flow · commit 2ca6742568e8 · 2026-06-19T14:53:31.000-07:00
diff --git a/modules/ROOT/pages/astream-subscriptions-exclusive.adoc b/modules/ROOT/pages/astream-subscriptions-exclusive.adoc
@@ -89,7 +89,7 @@ Caused by: org.apache.pulsar.client.api.PulsarClientException$ConsumerBusyExcept
 
 == See also
 
-* xref:astream-subscriptions.adoc[]
-* xref:astream-subscriptions-shared.adoc[]
-* xref:astream-subscriptions-failover.adoc[]
-* xref:astream-subscriptions-keyshared.adoc[]
+* xref:ROOT:astream-subscriptions.adoc[]
+* xref:ROOT:astream-subscriptions-shared.adoc[]
+* xref:ROOT:astream-subscriptions-failover.adoc[]
+* xref:ROOT:astream-subscriptions-keyshared.adoc[]
diff --git a/modules/ROOT/pages/astream-subscriptions-failover.adoc b/modules/ROOT/pages/astream-subscriptions-failover.adoc
@@ -5,7 +5,7 @@
 
 _Subscriptions_ in {pulsar-reg} describe which consumers are consuming data from a topic and how they want to consume that data.
 
-If an xref:astream-subscriptions-exclusive.adoc[exclusive] consumer fails, the topic backlog accumulates stale, unacknowledged messages.
+If an xref:ROOT:astream-subscriptions-exclusive.adoc[exclusive] consumer fails, the topic backlog accumulates stale, unacknowledged messages.
 {pulsar-short} solves this problem with failover subscriptions.
 In _failover subscriptions_, {pulsar-short} designates one primary consumer and multiple standby consumers.
 If the primary consumer disconnects, the standby consumers begin consuming the subsequent unacknowledged messages.
@@ -78,7 +78,7 @@ To test them, you can progressively end each `SimplePulsarConsumer` process, and
 
 == See also
 
-* xref:astream-subscriptions.adoc[]
-* xref:astream-subscriptions-exclusive.adoc[]
-* xref:astream-subscriptions-shared.adoc[]
-* xref:astream-subscriptions-keyshared.adoc[]
+* xref:ROOT:astream-subscriptions.adoc[]
+* xref:ROOT:astream-subscriptions-exclusive.adoc[]
+* xref:ROOT:astream-subscriptions-shared.adoc[]
+* xref:ROOT:astream-subscriptions-keyshared.adoc[]
diff --git a/modules/ROOT/pages/astream-subscriptions-keyshared.adoc b/modules/ROOT/pages/astream-subscriptions-keyshared.adoc
@@ -5,7 +5,7 @@
 
 _Subscriptions_ in {pulsar-reg} describe which consumers are consuming data from a topic and how they want to consume that data.
 
-{pulsar-short}'s xref:astream-subscriptions-shared.adoc[shared subscription] model can increase the message processing rate, but it risks losing message ordering guarantees.
+{pulsar-short}'s xref:ROOT:astream-subscriptions-shared.adoc[shared subscription] model can increase the message processing rate, but it risks losing message ordering guarantees.
 In a round-robin delivery, there's no way for the broker to know which messages are going to which consumer.
 
 _Key shared subscriptions_ allow multiple consumers to subscribe to a topic, and provide additional metadata in the form of _keys_ that link messages to specific consumers.
@@ -38,7 +38,7 @@ If you need to set fixed hash ranges, use the `<<use-stickyhashrange,stickyHashR
 === Use autoSplitHashRange
 
 To automatically assign hash ranges to consumers, use the `autoSplitHashRange` policy.
-Running multiple consumers with `autoSplitHashRange` balances the messaging load across all available consumers, like a xref:astream-subscriptions-shared.adoc[shared subscription].
+Running multiple consumers with `autoSplitHashRange` balances the messaging load across all available consumers, like a xref:ROOT:astream-subscriptions-shared.adoc[shared subscription].
 
 . In `src/main/java/com/datastax/pulsar`, create a `SimplePulsarConsumer.java` file with the following contents:
 +
@@ -211,7 +211,7 @@ Then, you can launch multiple instances of `SimplePulsarConsumer.java` to consum
 
 == See also
 
-* xref:astream-subscriptions.adoc[]
-* xref:astream-subscriptions-exclusive.adoc[]
-* xref:astream-subscriptions-shared.adoc[]
-* xref:astream-subscriptions-failover.adoc[]
+* xref:ROOT:astream-subscriptions.adoc[]
+* xref:ROOT:astream-subscriptions-exclusive.adoc[]
+* xref:ROOT:astream-subscriptions-shared.adoc[]
+* xref:ROOT:astream-subscriptions-failover.adoc[]
diff --git a/modules/ROOT/pages/astream-subscriptions-shared.adoc b/modules/ROOT/pages/astream-subscriptions-shared.adoc
@@ -70,14 +70,14 @@ The new consumer subscribes to the topic and consumes messages:
 ----
 
 Because this test uses shared subscriptions, you can attach multiple consumers to the topic.
-If you run this test with xref:astream-subscriptions-exclusive.adoc[exclusive subscriptions], you cannot attach more than once subscriber to the exclusive topic.
+If you run this test with xref:ROOT:astream-subscriptions-exclusive.adoc[exclusive subscriptions], you cannot attach more than once subscriber to the exclusive topic.
 
 To continue testing the shared subscription configuration, you can continue running new instances of `SimplePulsarConsumer.java` in new terminal windows.
 All the consumers subscribe to the topic and consume messages in a round-robin fashion.
 
 == See also
 
-* xref:astream-subscriptions.adoc[]
-* xref:astream-subscriptions-exclusive.adoc[]
-* xref:astream-subscriptions-failover.adoc[]
-* xref:astream-subscriptions-keyshared.adoc[]
+* xref:ROOT:astream-subscriptions.adoc[]
+* xref:ROOT:astream-subscriptions-exclusive.adoc[]
+* xref:ROOT:astream-subscriptions-failover.adoc[]
+* xref:ROOT:astream-subscriptions-keyshared.adoc[]
diff --git a/modules/ROOT/pages/astream-subscriptions.adoc b/modules/ROOT/pages/astream-subscriptions.adoc
@@ -27,13 +27,12 @@ pulsarConsumer = pulsarClient.newConsumer(Schema.BYTES)
 
 == Subscription types
 
-* xref:astream-subscriptions-exclusive.adoc[Exclusive subscriptions]
-* xref:astream-subscriptions-shared.adoc[Shared subscriptions]
-* xref:astream-subscriptions-failover.adoc[Failover subscriptions]
-* xref:astream-subscriptions-keyshared.adoc[Key shared subscriptions]
+* xref:ROOT:astream-subscriptions-exclusive.adoc[Exclusive subscriptions]
+* xref:ROOT:astream-subscriptions-shared.adoc[Shared subscriptions]
+* xref:ROOT:astream-subscriptions-failover.adoc[Failover subscriptions]
+* xref:ROOT:astream-subscriptions-keyshared.adoc[Key shared subscriptions]
 
 == See also
 
 * xref:getting-started:index.adoc[]
-* xref:developing:starlight.adoc[]
-
+* xref:developing:starlight.adoc[]
diff --git a/modules/developing/pages/astream-functions.adoc b/modules/developing/pages/astream-functions.adoc
@@ -177,7 +177,7 @@ mvn package
 [#deploy-the-function-with-the-pulsar-cli]
 === Deploy the function with the {pulsar-short} CLI
 
-. If you haven't done so already, xref:configure-pulsar-env.adoc[set up your environment for the {pulsar-short} binaries].
+. If you haven't done so already, xref:developing:configure-pulsar-env.adoc[set up your environment for the {pulsar-short} binaries].
 
 . Create a deployment configuration YAML file that defines the function metadata and associated topics:
 +
diff --git a/modules/developing/pages/clients/index.adoc b/modules/developing/pages/clients/index.adoc
@@ -10,9 +10,9 @@ You should use this API version or higher.
 
 For more information and examples, see the following:
 
-* xref:clients/csharp-produce-consume.adoc[C#]
-* xref:clients/golang-produce-consume.adoc[Golang]
-* xref:clients/java-produce-consume.adoc[Java]
-* xref:clients/nodejs-produce-consume.adoc[Node.js]
-* xref:clients/python-produce-consume.adoc[Python]
-* xref:clients/spring-produce-consume.adoc[Spring Boot]
+* xref:developing:clients/csharp-produce-consume.adoc[C#]
+* xref:developing:clients/golang-produce-consume.adoc[Golang]
+* xref:developing:clients/java-produce-consume.adoc[Java]
+* xref:developing:clients/nodejs-produce-consume.adoc[Node.js]
+* xref:developing:clients/python-produce-consume.adoc[Python]
+* xref:developing:clients/spring-produce-consume.adoc[Spring Boot]
diff --git a/modules/developing/pages/configure-pulsar-env.adoc b/modules/developing/pages/configure-pulsar-env.adoc
@@ -80,4 +80,4 @@ Run some commands to validate the binary configuration.
 
 == See also
 
-* xref:produce-consume-pulsar-client.adoc[]
+* xref:developing:produce-consume-pulsar-client.adoc[]
diff --git a/modules/developing/pages/produce-consume-astra-portal.adoc b/modules/developing/pages/produce-consume-astra-portal.adoc
@@ -31,5 +31,5 @@ Produced and consumed messages are printed in a chat style format in the **Test
 
 == See also
 
-* xref:astream-functions.adoc[]
-* xref:astream-cdc.adoc[]
+* xref:developing:astream-functions.adoc[]
+* xref:developing:astream-cdc.adoc[]
diff --git a/modules/developing/pages/produce-consume-pulsar-client.adoc b/modules/developing/pages/produce-consume-pulsar-client.adoc
@@ -243,7 +243,7 @@ Delete a source connector::
 == See also
 
 * xref:developing:clients/index.adoc[]
-* xref:astream-functions.adoc[]
-* xref:astream-cdc.adoc[]
+* xref:developing:astream-functions.adoc[]
+* xref:developing:astream-cdc.adoc[]
 * xref:connectors:index.adoc[]
 * xref:developing:astream-functions.adoc[]
diff --git a/modules/operations/pages/astream-pricing.adoc b/modules/operations/pages/astream-pricing.adoc
@@ -48,13 +48,13 @@ These include, but are not limited to, the following:
 
 == Limits
 
-Regardless of your plan or cluster type, {product} applies xref:astream-limits.adoc[guardrails and limits] on resource creation to ensure best practices, foster availability, and promote optimal configurations for your databases.
+Regardless of your plan or cluster type, {product} applies xref:operations:astream-limits.adoc[guardrails and limits] on resource creation to ensure best practices, foster availability, and promote optimal configurations for your databases.
 
 Streaming Capacity Units have fewer limits than shared clusters.
 
 == Regions
 
-With shared clusters, you can create tenants in any of the xref:astream-regions.adoc[supported regions].
+With shared clusters, you can create tenants in any of the xref:operations:astream-regions.adoc[supported regions].
 
 Streaming Capacity Units are open to almost any public cloud region.
 For this reason, Streaming Capacity Units offer more flexibility for xref:operations:astream-georeplication.adoc[georeplication].
diff --git a/modules/operations/pages/astream-scrape-metrics.adoc b/modules/operations/pages/astream-scrape-metrics.adoc
@@ -141,6 +141,6 @@ A tenant can only access its own metrics on the broker pod or function worker po
 
 == See also
 
-* xref:monitoring/index.adoc[]
+* xref:operations:monitoring/index.adoc[]
 * xref:getting-started:index.adoc[]
 * https://prometheus.io/docs/introduction/overview/[Prometheus documentation]
diff --git a/modules/operations/pages/monitoring/index.adoc b/modules/operations/pages/monitoring/index.adoc
@@ -15,7 +15,7 @@ For a complete {pulsar-short} metrics reference, see:
 
 * https://pulsar.apache.org/docs/reference-metrics/#topic-metrics[Topic metrics]
 
-For a complete {product} metrics reference, see xref:monitoring/metrics.adoc[].
+For a complete {product} metrics reference, see xref:operations:monitoring/metrics.adoc[].
 
 == {product} metrics
 
@@ -263,7 +263,7 @@ The following table gives the list of recommended source connector metrics as a
 [IMPORTANT]
 ====
 Do _not_ aggregate metrics on shared clusters because one cluster can be shared among multiple organizations.
-For more information, see xref:astream-limits.adoc[] and xref:operations:astream-pricing.adoc[].
+For more information, see xref:operations:astream-limits.adoc[] and xref:operations:astream-pricing.adoc[].
 ====
 
 Each externally exposed raw {product} metric is reported at a very low level, at each individual server instance (the `exported_instance` label) and each topic partition (the `topic` label). The same raw metrics could come from multiple server instances. From an {product} user's perspective, the direct monitoring of raw metrics is not really useful. Raw metrics need to be aggregated first - for example, by averaging or summing the raw metrics over a period of time.
@@ -417,6 +417,6 @@ If your receive too many false alarms, adjust the alert threshold to a higher va
 
 == See also
 
-* xref:monitoring/metrics.adoc[]
-* xref:monitoring/integration.adoc[]
-* xref:monitoring/new-relic.adoc[]
+* xref:operations:monitoring/metrics.adoc[]
+* xref:operations:monitoring/integration.adoc[]
+* xref:operations:monitoring/new-relic.adoc[]
diff --git a/modules/operations/pages/monitoring/integration.adoc b/modules/operations/pages/monitoring/integration.adoc
@@ -96,11 +96,10 @@ Make sure the additional scrape job is in `UP` status.
 If not, review the configuration instructions and YAML examples to ensure your configuration is correct.
 +
 If the additional scrape job returns a `401 Unauthorized` error, make sure your {pulsar-short} JWT isn't expired.
-For more information, see xref:astream-token-gen.adoc[].
+For more information, see xref:operations:astream-token-gen.adoc[].
 
 == See also
 
-* xref:monitoring/index.adoc[]
-* xref:monitoring/metrics.adoc[]
-* xref:monitoring/new-relic.adoc[]
-
+* xref:operations:monitoring/index.adoc[]
+* xref:operations:monitoring/metrics.adoc[]
+* xref:operations:monitoring/new-relic.adoc[]
diff --git a/modules/operations/pages/monitoring/metrics.adoc b/modules/operations/pages/monitoring/metrics.adoc
@@ -1,10 +1,10 @@
 = Grafana dashboards for {product} metrics
 
 {company} provides Grafana dashboards for core message processing for exposed {product} metrics.
-Use these dashboards as a starting point for xref:monitoring/index.adoc[monitoring your {product} deployment], and then customize them as needed.
+Use these dashboards as a starting point for xref:operations:monitoring/index.adoc[monitoring your {product} deployment], and then customize them as needed.
 
 Dashboards are available for scraping metrics {pulsar-short}'s tenant, namespace, and topic levels:
 
-* Tenant level metrics: xref:monitoring/overview-dashboard.adoc[]
-* Namespace level metrics: xref:monitoring/namespace-dashboard.adoc[]
-* Topic level metrics: xref:monitoring/topic-dashboard.adoc[]
+* Tenant level metrics: xref:operations:monitoring/overview-dashboard.adoc[]
+* Namespace level metrics: xref:operations:monitoring/namespace-dashboard.adoc[]
+* Topic level metrics: xref:operations:monitoring/topic-dashboard.adoc[]
diff --git a/modules/operations/pages/monitoring/namespace-dashboard.adoc b/modules/operations/pages/monitoring/namespace-dashboard.adoc
@@ -45,5 +45,5 @@ Georeplication displays the time series metrics chart summarized at the namespac
 
 == See also
 
-* xref:monitoring/overview-dashboard.adoc[]
-* xref:monitoring/topic-dashboard.adoc[]
+* xref:operations:monitoring/overview-dashboard.adoc[]
+* xref:operations:monitoring/topic-dashboard.adoc[]
diff --git a/modules/operations/pages/monitoring/new-relic.adoc b/modules/operations/pages/monitoring/new-relic.adoc
@@ -4,13 +4,13 @@ While there are multiple ways to https://docs.newrelic.com/docs/infrastructure/p
 
 == Prerequisites
 
-* Review xref:monitoring/index.adoc[].
+* Review xref:operations:monitoring/index.adoc[].
 * https://docs.newrelic.com/[Set up a New Relic account.]
 * Save your New Relic license key locally.
 
 == Prepare the extra Prometheus server
 
-xref:monitoring/integration.adoc[Install an extra Prometheus server] to act as a bridge to forward scraped {product} metrics to New Relic.
+xref:operations:monitoring/integration.adoc[Install an extra Prometheus server] to act as a bridge to forward scraped {product} metrics to New Relic.
 
 This is required because {product} is a managed service, and you cannot modify the {product} Prometheus server as required by the New Relic Prometheus write integration.
 
@@ -64,6 +64,6 @@ prometheus:
 
 == See also
 
-* For a list of exposed endpoints for {product} metrics, see xref:monitoring/metrics.adoc[].
-* To scrape {product} metrics in Kubernetes with an external Prometheus server, see xref:monitoring/integration.adoc[].
-* To scrape {product} metrics into New Relic, see xref:monitoring/new-relic.adoc[].
+* For a list of exposed endpoints for {product} metrics, see xref:operations:monitoring/metrics.adoc[].
+* To scrape {product} metrics in Kubernetes with an external Prometheus server, see xref:operations:monitoring/integration.adoc[].
+* To scrape {product} metrics into New Relic, see xref:operations:monitoring/new-relic.adoc[].
diff --git a/modules/operations/pages/monitoring/overview-dashboard.adoc b/modules/operations/pages/monitoring/overview-dashboard.adoc
@@ -49,5 +49,5 @@ Messaging displays the time series metrics chart summarized at the tenant level.
 
 == See also
 
-* xref:monitoring/namespace-dashboard.adoc[]
-* xref:monitoring/topic-dashboard.adoc[]
+* xref:operations:monitoring/namespace-dashboard.adoc[]
+* xref:operations:monitoring/topic-dashboard.adoc[]
diff --git a/modules/operations/pages/monitoring/topic-dashboard.adoc b/modules/operations/pages/monitoring/topic-dashboard.adoc
@@ -62,5 +62,5 @@ Georeplication displays the time series metrics chart summarized at the topic le
 
 == See also
 
-* xref:monitoring/overview-dashboard.adoc[]
-* xref:monitoring/namespace-dashboard.adoc[]
+* xref:operations:monitoring/overview-dashboard.adoc[]
+* xref:operations:monitoring/namespace-dashboard.adoc[]

Original file line number	Diff line number	Diff line change
`@@ -177,7 +177,7 @@ mvn package`
`177`	`177`	`[#deploy-the-function-with-the-pulsar-cli]`
`178`	`178`	`=== Deploy the function with the {pulsar-short} CLI`
`179`	`179`
`180`		`-. If you haven't done so already, xref:configure-pulsar-env.adoc[set up your environment for the {pulsar-short} binaries].`
	`180`	`+. If you haven't done so already, xref:developing:configure-pulsar-env.adoc[set up your environment for the {pulsar-short} binaries].`
`181`	`181`
`182`	`182`	`. Create a deployment configuration YAML file that defines the function metadata and associated topics:`
`183`	`183`	`+`
Original file line number	Diff line number	Diff line change
`@@ -80,4 +80,4 @@ Run some commands to validate the binary configuration.`
`80`	`80`
`81`	`81`	`== See also`
`82`	`82`
`83`		`-* xref:produce-consume-pulsar-client.adoc[]`
	`83`	`+* xref:developing:produce-consume-pulsar-client.adoc[]`