From b1f54fae1a281cc9e5d3a7a27ec982713536f64f Mon Sep 17 00:00:00 2001 From: shainaraskas <58563081+shainaraskas@users.noreply.github.com> Date: Tue, 20 Aug 2024 10:58:45 -0400 Subject: [PATCH] Apply suggestions from code review --- docs/reference/ccr/auto-follow.asciidoc | 2 +- docs/reference/ccr/bi-directional-disaster-recovery.asciidoc | 2 +- docs/reference/ccr/getting-started.asciidoc | 2 +- docs/reference/ccr/managing.asciidoc | 2 +- docs/reference/ccr/uni-directional-disaster-recovery.asciidoc | 2 +- docs/reference/ccr/upgrading.asciidoc | 2 +- docs/reference/ilm/start-stop.asciidoc | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/reference/ccr/auto-follow.asciidoc b/docs/reference/ccr/auto-follow.asciidoc index 200cce4bbe1bd..0b8ade90aae2a 100644 --- 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 <> 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 index 45cfd55728719..b491e90053031 100644 --- 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 <>. The following tutorial is designed for data streams which support +bi-directional {ccr}. The following tutorial is designed for data streams which support <> and <>. 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 index 8af275eb1db93..2a0e3bcc5681f 100644 --- 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 <> (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 index 723ea3d2265e1..d7db04cf60f07 100644 --- 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 <> 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 index b8ace86b6c21e..731fbc0b242c9 100644 --- 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 <>. You can also visit <> 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 <> 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 index 59308f206485b..6976042872260 100644 --- a/docs/reference/ccr/upgrading.asciidoc +++ b/docs/reference/ccr/upgrading.asciidoc @@ -5,7 +5,7 @@ Upgrading clusters ++++ -Clusters that are actively using <> 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 index 810f8a8285a98..2965cc5cb932f 100644 --- 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<> to suspend management operations for all indices. +You can stop <> 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.