Apply suggestions from code review

stefnestor · Aug 20, 2024 · b1f54fa · b1f54fa
1 parent 7f083f3
commit b1f54fa
Show file tree

Hide file tree

Showing 7 changed files with 7 additions and 7 deletions.
diff --git a/docs/reference/ccr/auto-follow.asciidoc b/docs/reference/ccr/auto-follow.asciidoc
@@ -28,7 +28,7 @@ Auto-follow patterns are especially useful with
 new indices on the cluster containing the leader index.
 
 [[ccr-access-ccr-auto-follow]]
-To start using <<xpack-ccr,{ccr}>> auto-follow patterns from Stack Management in {kib}, select
+To start using {ccr} auto-follow patterns from Stack Management in {kib}, select
 *Cross-Cluster Replication* from the side navigation and choose the
 *Auto-follow patterns* tab.
 

diff --git a/docs/reference/ccr/bi-directional-disaster-recovery.asciidoc b/docs/reference/ccr/bi-directional-disaster-recovery.asciidoc
@@ -20,7 +20,7 @@ DELETE /_data_stream/*
 ////
 
 Learn how to set up disaster recovery between two clusters based on
-bi-directional <<xpack-ccr,{ccr}>>. The following tutorial is designed for data streams which support
+bi-directional {ccr}. The following tutorial is designed for data streams which support
 <<update-docs-in-a-data-stream-by-query,update by query>> and <<delete-docs-in-a-data-stream-by-query,delete by query>>. You can only perform these actions on the leader index.
 
 This tutorial works with {ls} as the source of ingestion. It takes advantage of a {ls} feature where {logstash-ref}/plugins-outputs-elasticsearch.html[the {ls} output to {es}] can be load balanced across an array of hosts specified. {beats} and {agents} currently do not

diff --git a/docs/reference/ccr/getting-started.asciidoc b/docs/reference/ccr/getting-started.asciidoc
@@ -46,7 +46,7 @@ PUT /server-metrics
 // TESTSETUP
 ////
 
-Use this guide to set up <<xpack-ccr,{ccr}>> (CCR) between clusters in two
+Use this guide to set up {ccr} (CCR) between clusters in two
 datacenters. Replicating your data across datacenters provides several benefits:
 
 * Brings data closer to your users or application server to reduce latency and

diff --git a/docs/reference/ccr/managing.asciidoc b/docs/reference/ccr/managing.asciidoc
@@ -2,7 +2,7 @@
 
 [[ccr-managing]]
 === Manage {ccr}
-Use the following information to manage <<xpack-ccr,{ccr}>> tasks, such as inspecting
+Use the following information to manage {ccr} tasks, such as inspecting
 replication progress, pausing and resuming replication, recreating a follower
 index, and terminating replication.
 

diff --git a/docs/reference/ccr/uni-directional-disaster-recovery.asciidoc b/docs/reference/ccr/uni-directional-disaster-recovery.asciidoc
@@ -20,7 +20,7 @@ DELETE kibana_sample_data_ecommerce
 ////
 
 
-Learn how to failover and failback between two clusters based on uni-directional <<xpack-ccr,{ccr}>>. You can also visit <<ccr-disaster-recovery-bi-directional-tutorial>> to set up replicating data streams that automatically failover and failback without human intervention.
+Learn how to failover and failback between two clusters based on uni-directional {ccr}. You can also visit <<ccr-disaster-recovery-bi-directional-tutorial>> to set up replicating data streams that automatically failover and failback without human intervention.
 
 * Setting up uni-directional {ccr} replicated from `clusterA`
 to `clusterB`.

diff --git a/docs/reference/ccr/upgrading.asciidoc b/docs/reference/ccr/upgrading.asciidoc
@@ -5,7 +5,7 @@
 <titleabbrev>Upgrading clusters</titleabbrev>
 ++++
 
-Clusters that are actively using <<xpack-ccr,{ccr}>> require a careful approach to upgrades.
+Clusters that are actively using {ccr} require a careful approach to upgrades.
 The following conditions could cause index following to fail during rolling
 upgrades:
 

diff --git a/docs/reference/ilm/start-stop.asciidoc b/docs/reference/ilm/start-stop.asciidoc
@@ -5,7 +5,7 @@
 By default, the {ilm-init} service is in the `RUNNING` state and manages 
 all indices that have lifecycle policies. 
 
-You can stop<<index-lifecycle-management,{ilm}>> to suspend management operations for all indices.
+You can stop <<index-lifecycle-management,{ilm}>> to suspend management operations for all indices.
 For example, you might stop {ilm} when performing scheduled maintenance or making
 changes to the cluster that could impact the execution of {ilm-init} actions.