[DOCS] Move ES glossary to Stack docs (#74579)

The ES glossary is now incorporated into the [Elastic glossary](https://www.elastic.co/guide/en/elastic-stack-glossary/current/terms.html).

Depends on https://github.com/elastic/stack-docs/pull/1722 and https://github.com/elastic/docs/pull/2141

docs/reference/glossary.asciidoc

@@ -1,507 +0,0 @@
-////
-============
-IMPORTANT
-Add new terms to the Stack Docs glossary:
-https://github.com/elastic/stack-docs/tree/master/docs/en/glossary
-============
-////
-
-[glossary]
-[[glossary]]
-= Glossary
-
-[glossary]
-[[glossary-alias]] alias::
-// tag::alias-def[]
-An alias is a secondary name for a group of <<glossary-data-stream,data
-streams>> or <<glossary-index,indices>>. Most {es} APIs accept an alias in place
-of a data stream or index name. See {ref}/alias.html[Aliases].
-// end::alias-def[]
-
-[[glossary-analysis]] analysis::
-// tag::analysis-def[]
-Process of converting unstructured <<glossary-text,text>> into a format
-optimized for search. See {ref}/analysis.html[Text analysis].
-// end::analysis-def[]
-
-[[glossary-api-key]] API key::
-// tag::api-key-def[]
-Unique identifier for authentication in {es}. When
-{ref}/encrypting-communications.html[transport layer security (TLS)] is enabled,
-all requests must be authenticated using an API key or a username and password.
-See the {ref}/security-api-create-api-key.html[Create API key API].
-// end::api-key-def[]
-
-[[glossary-auto-follow-pattern]] auto-follow pattern::
-// tag::auto-follow-pattern-def[]
-<<glossary-index-pattern,Index pattern>> that automatically configures new
-<<glossary-index,indices>> as <<glossary-follower-index,follower indices>> for
-<<glossary-ccr,{ccr}>>. See {ref}/ccr-auto-follow.html[Manage auto-follow
-patterns].
-// end::auto-follow-pattern-def[]
-
-[[glossary-cluster]] cluster::
-// tag::cluster-def[]
-A group of one or more connected {es} <<glossary-node,nodes>>. See
-{ref}/scalability.html[Clusters, nodes, and shards].
-// end::cluster-def[]
-
-[[glossary-cold-phase]] cold phase::
-// tag::cold-phase-def[]
-Third possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In the
-cold phase, data is no longer updated and seldom <<glossary-query,queried>>. The
-data still needs to be searchable, but it’s okay if those queries are slower.
-See {ref}/ilm-index-lifecycle.html[Index lifecycle].
-// end::cold-phase-def[]
-
-[[glossary-cold-tier]] cold tier::
-// tag::cold-tier-def[]
-<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that hold
-time series data that is accessed occasionally and not normally updated. See
-{ref}/data-tiers.html[Data tiers].
-// end::cold-tier-def[]
-
-[[glossary-component-template]] component template::
-// tag::component-template-def[]
-Building block for creating <<glossary-index-template,index templates>>. A
-component template can specify <<glossary-mapping,mappings>>,
-{ref}/index-modules.html[index settings], and <<glossary-alias,aliases>>. See
-{ref}/index-templates.html[index templates].
-// end::component-template-def[]
-
-[[glossary-content-tier]] content tier::
-// tag::content-tier-def[]
-<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that
-handle the <<glossary-index,indexing>> and <<glossary-query,query>> load for
-content, such as a product catalog. See {ref}/data-tiers.html[Data tiers].
-// end::content-tier-def[]
-
-[[glossary-ccr]] {ccr} ({ccr-init})::
-// tag::ccr-def[]
-Replicates <<glossary-data-stream,data streams>> and <<glossary-index,indices>>
-from <<glossary-remote-cluster,remote clusters>> in a
-<<glossary-local-cluster,local cluster>>. See {ref}/xpack-ccr.html[{ccr-cap}].
-// end::ccr-def[]
-
-[[glossary-ccs]] {ccs} (CCS)::
-// tag::ccs-def[]
-Searches <<glossary-data-stream,data streams>> and <<glossary-index,indices>> on
-<<glossary-remote-cluster,remote clusters>> from a
-<<glossary-local-cluster,local cluster>>. See
-{ref}/modules-cross-cluster-search.html[Search across clusters].
-// end::ccs-def[]
-
-[[glossary-data-stream]] data stream::
-// tag::data-stream-def[]
-Named resource used to manage time series data. A data stream stores data across
-multiple backing <<glossary-index,indices>>. See {ref}/data-streams.html[Data
-streams].
-// end::data-stream-def[]
-
-[[glossary-data-tier]] data tier::
-// tag::data-tier-def[]
-Collection of <<glossary-node,nodes>> with the same {ref}/modules-node.html[data
-role] that typically share the same hardware profile. Data tiers include the
-<<glossary-content-tier, content tier>>, <<glossary-hot-tier, hot tier>>,
-<<glossary-warm-tier, warm tier>>, <<glossary-cold-tier, cold tier>>, and
-<<glossary-frozen-tier,frozen tier>>. See {ref}/data-tiers.html[Data tiers].
-// end::data-tier-def[]
-
-[[glossary-delete-phase]] delete phase::
-// tag::delete-phase-def[]
-Last possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In the
-delete phase, an <<glossary-index,index>> is no longer needed and can safely be
-deleted. See {ref}/ilm-index-lifecycle.html[Index lifecycle].
-// end::delete-phase-def[]
-
-[[glossary-document]] document::
-// tag::document-def[]
-JSON object containing data stored in {es}. See
-{ref}/documents-indices.html[Documents and indices].
-// end::document-def[]
-
-[[glossary-eql]]
-Event Query Language (EQL)::
-// tag::eql-def[]
-<<glossary-query,Query>> language for event-based time series data, such as
-logs, metrics, and traces. EQL supports matching for event sequences. See
-{ref}/eql.html[EQL].
-// end::eql-def[]
-
-[[glossary-field]] field::
-// tag::field-def[]
-Key-value pair in a <<glossary-document,document>>. See
-{ref}/mapping.html[Mapping].
-// end::field-def[]
-
-[[glossary-filter]] filter::
-// tag::filter-def[]
-<<glossary-query,Query>> that does not score matching documents. See
-{ref}/query-filter-context.html[filter context].
-// end::filter-def[]
-
-[[glossary-flush]] flush::
-// tag::flush-def[]
-Writes data from the {ref}/index-modules-translog.html[transaction log] to disk
-for permanent storage. See the {ref}/indices-flush.html[flush API].
-// end::flush-def[]
-
-[[glossary-follower-index]] follower index::
-// tag::follower-index-def[]
-Target <<glossary-index,index>> for <<glossary-ccr,{ccr}>>. A follower index
-exists in a <<glossary-local-cluster,local cluster>> and replicates a
-<<glossary-leader-index,leader index>>. See {ref}/xpack-ccr.html[{ccr-cap}].
-// end::follower-index-def[]
-
-[[glossary-force-merge]] force merge::
-// tag::force-merge-def[]
-// tag::force-merge-def-short[]
-Manually triggers a <<glossary-merge,merge>> to reduce the number of
-<<glossary-segment,segments>> in an index's <<glossary-shard,shards>>.
-// end::force-merge-def-short[]
-See the {ref}/indices-forcemerge.html[force merge API].
-// end::force-merge-def[]
-
-[[glossary-frozen-phase]] frozen phase::
-// tag::frozen-phase-def[]
-Fourth possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In
-the frozen phase, an <<glossary-index,index>> is no longer updated and
-<<glossary-query,queried>> rarely. The information still needs to be searchable,
-but it’s okay if those queries are extremely slow. See
-{ref}/ilm-index-lifecycle.html[Index lifecycle].
-// end::frozen-phase-def[]
-
-[[glossary-frozen-tier]] frozen tier::
-// tag::frozen-tier-def[]
-<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that
-hold time series data that is accessed rarely and not normally updated. See
-{ref}/data-tiers.html[Data tiers].
-// end::frozen-tier-def[]
-
-[[glossary-hidden-index]] hidden data stream or index::
-// tag::hidden-index-def[]
-<<glossary-data-stream,Data stream>> or <<glossary-index,index>> excluded from
-most <<glossary-index-pattern,index patterns>> by default. See
-{ref}/multi-index.html#hidden[Hidden data streams and indices].
-// end::hidden-index-def[]
-
-[[glossary-hot-phase]] hot phase::
-// tag::hot-phase-def[]
-First possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In
-the hot phase, an <<glossary-index,index>> is actively updated and queried. See
-{ref}/ilm-index-lifecycle.html[Index lifecycle].
-// end::hot-phase-def[]
-
-[[glossary-hot-tier]] hot tier::
-// tag::hot-tier-def[]
-<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that
-handle the <<glossary-index,indexing>> load for time series data, such as logs or
-metrics. This tier holds your most recent, most frequently accessed data. See
-{ref}/data-tiers.html[Data tiers].
-// end::hot-tier-def[]
-
-[[glossary-id]] ID::
-// tag::id-def[]
-Identifier for a <<glossary-document,document>>. Document IDs must be unique
-within an <<glossary-index,index>>. See the {ref}/mapping-id-field.html[`_id`
-field].
-// end::id-def[]
-
-[[glossary-index]] index::
-// tag::index-def[]
-. Collection of JSON <<glossary-document,documents>>. See
-{ref}/documents-indices.html[Documents and indices].
-
-. To add one or more JSON documents to {es}. This process is called indexing.
-// end::index-def[]
-
-[[glossary-index-lifecycle]] index lifecycle::
-// tag::index-lifecycle-def[]
-Five phases an <<glossary-index,index>> can transition through:
-<<glossary-hot-phase,hot>>, <<glossary-warm-phase,warm>>,
-<<glossary-cold-phase,cold>>, <<glossary-frozen-phase,frozen>>,
-and <<glossary-delete-phase,delete>>. See {ref}/ilm-policy-definition.html[Index
-lifecycle].
-// end::index-lifecycle-def[]
-
-[[glossary-index-lifecycle-policy]] index lifecycle policy::
-// tag::index-lifecycle-policy-def[]
-Specifies how an <<glossary-index,index>> moves between phases in the
-<<glossary-index-lifecycle,index lifecycle>> and what actions to perform during
-each phase. See {ref}/ilm-policy-definition.html[Index lifecycle].
-// end::index-lifecycle-policy-def[]
-
-[[glossary-index-pattern]] index pattern::
-// tag::index-pattern-def[]
-String containing a wildcard (`*`) pattern that can match multiple
-<<glossary-data-stream,data streams>>, <<glossary-index,indices>>, or
-<<glossary-alias,aliases>>. See {ref}/multi-index.html[Multi-target syntax].
-// end::index-pattern-def[]
-
-[[glossary-index-template]] index template::
-// tag::index-template-def[]
-Automatically configures the <<glossary-mapping,mappings>>,
-{ref}/index-modules.html[index settings], and <<glossary-alias,aliases>>
-of new <<glossary-index,indices>> that match its <<glossary-index-pattern,index
-pattern>>. You can also use index templates to create
-<<glossary-data-stream,data streams>>. See {ref}/index-templates.html[Index
-templates].
-// end::index-template-def[]
-
-[[glossary-leader-index]] leader index::
-// tag::leader-index-def[]
-Source <<glossary-index,index>> for <<glossary-ccr,{ccr}>>. A leader index
-exists on a <<glossary-remote-cluster,remote cluster>> and is replicated to
-<<glossary-follower-index,follower indices>>. See
-{ref}/xpack-ccr.html[{ccr-cap}].
-// end::leader-index-def[]
-
-[[glossary-local-cluster]] local cluster::
-// tag::local-cluster-def[]
-<<glossary-cluster,Cluster>> that pulls data from a
-<<glossary-remote-cluster,remote cluster>> in <<glossary-ccs,{ccs}>> or
-<<glossary-ccr,{ccr}>>. See {ref}/modules-remote-clusters.html[Remote clusters].
-// end::local-cluster-def[]
-
-[[glossary-mapping]] mapping::
-// tag::mapping-def[]
-Defines how a <<glossary-document,document>>, its <<glossary-field,fields>>, and
-its metadata are stored in {es}. Similar to a schema definition. See
-{ref}/mapping.html[Mapping].
-// end::mapping-def[]
-
-[[glossary-merge]] merge::
-// tag::merge-def[]
-Process of combining a <<glossary-shard,shard>>'s smaller Lucene
-<<glossary-segment,segments>> into a larger one. {es} manages merges
-automatically.
-// end::merge-def[]
-
-[[glossary-multi-field]] multi-field::
-// tag::multi-field-def[]
-A <<glossary-field,field>> that's <<glossary-mapping,mapped>> in multiple ways.
-See the {ref}/multi-fields.html[`fields` mapping parameter].
-// end::multi-field-def[]
-
-[[glossary-node]] node::
-// tag::node-def[]
-A single {es} server. One or more nodes can form a <<glossary-cluster,cluster>>.
-See {ref}/scalability.html[Clusters, nodes, and shards].
-// end::node-def[]
-
-[[glossary-primary-shard]] primary shard::
-// tag::primary-shard-def[]
-Lucene instance containing some or all data for an <<glossary-index,index>>.
-When you index a <<glossary-document,document>>, {es} adds the document to
-primary shards before <<glossary-replica-shard,replica shards>>. See
-{ref}/scalability.html[Clusters, nodes, and shards].
-// end::primary-shard-def[]
-
-[[glossary-query]] query::
-// tag::query-def[]
-Request for information about your data. You can think of a query as a
-question, written in a way {es} understands. See
-{ref}/search-your-data.html[Search your data].
-// end::query-def[]
-
-[[glossary-recovery]] recovery::
-// tag::recovery-def[]
-Process of syncing a <<glossary-replica-shard,replica shard>> from a
-<<glossary-primary-shard,primary shard>>. Upon completion, the replica shard is
-available for searches. See the {ref}/indices-recovery.html[index recovery API].
-// end::recovery-def[]
-
-[[glossary-reindex]] reindex::
-// tag::reindex-def[]
-Copies documents from a source to a destination. The source and destination can
-be a <<glossary-data-stream,data stream>>, <<glossary-index,index>>, or
-<<glossary-alias,alias>>. See the {ref}/docs-reindex.html[Reindex API].
-// end::reindex-def[]
-
-[[glossary-remote-cluster]] remote cluster::
-// tag::remote-cluster-def[]
-A separate <<glossary-cluster,cluster>>, often in a different data center or
-locale, that contains <<glossary-index,indices>> that can be replicated or
-searched by the <<glossary-local-cluster,local cluster>>. The connection to a
-remote cluster is unidirectional. See {ref}/modules-remote-clusters.html[Remote
-clusters].
-// end::remote-cluster-def[]
-
-[[glossary-replica-shard]] replica shard::
-// tag::replica-shard-def[]
-Copy of a <<glossary-primary-shard,primary shard>>. Replica shards can improve
-search performance and resiliency by distributing data across multiple
-<<glossary-node,nodes>>. See {ref}/scalability.html[Clusters, nodes, and
-shards].
-// end::replica-shard-def[]
-
-[[glossary-rollover]] rollover::
-// tag::rollover-def[]
-// tag::rollover-def-short[]
-Creates a new write index when the current one reaches a certain size, number of
-docs, or age.
-// end::rollover-def-short[]
-A rollover can target a <<glossary-data-stream,data stream>> or an
-<<glossary-alias,alias>> with a write index.
-// end::rollover-def[]
-
-[[glossary-rollup]] rollup::
-// tag::rollup-def[]
-Summarizes high-granularity data into a more compressed format to maintain access
-to historical data in a cost-effective way. See
-{ref}/xpack-rollup.html[Roll up your data].
-// end::rollup-def[]
-
-[[glossary-rollup-index]] rollup index::
-// tag::rollup-index-def[]
-Special type of <<glossary-index,index>> for storing historical data at reduced
-granularity. Documents are summarized and indexed into a rollup index by a
-<<glossary-rollup-job,rollup job>>. See {ref}/xpack-rollup.html[Rolling up
-historical data].
-// end::rollup-index-def[]
-
-[[glossary-rollup-job]] rollup job::
-// tag::rollup-job-def[]
-Background task that runs continuously to summarize documents in an
-<<glossary-index,index>> and index the summaries into a separate rollup index.
-The job configuration controls what data is rolled up and how often. See
-{ref}/xpack-rollup.html[Rolling up historical data].
-// end::rollup-job-def[]
-
-[[glossary-routing]] routing::
-// tag::routing-def[]
-Process of sending and retrieving data from a specific
-<<glossary-primary-shard,primary shard>>. {es} uses a hashed routing value to
-choose this shard. You can provide a routing value in
-<<glossary-index,indexing>> and search requests to take advantage of caching.
-See the {ref}/mapping-routing-field.html[`_routing` field].
-// end::routing-def[]
-
-[[glossary-runtime-fields]] runtime field::
-// tag::runtime-fields-def[]
-<<glossary-field,Field>> that is evaluated at query time. You access runtime
-fields from the search API like any other field, and {es} sees runtime fields no
-differently. See {ref}/runtime.html[Runtime fields].
-// end::runtime-fields-def[]
-
-[[glossary-searchable-snapshot]] searchable snapshot::
-// tag::searchable-snapshot-def[]
-<<glossary-snapshot,Snapshot>> of an <<glossary-index,index>> mounted as a
-<<glossary-searchable-snapshot-index,searchable snapshot index>>. You can search
-this index like a regular index. See {ref}/searchable-snapshots.html[searchable
-snapshots].
-// end::searchable-snapshot-def[]
-
-[[glossary-searchable-snapshot-index]] searchable snapshot index::
-// tag::searchable-snapshot-index-def[]
-<<glossary-index,Index>> whose data is stored in a
-<<glossary-snapshot,snapshot>>. Searchable snapshot indices do not need
-<<glossary-replica-shard,replica shards>> for resilience, since their data is
-reliably stored outside the cluster. See
-{ref}/searchable-snapshots.html[searchable snapshots].
-// end::searchable-snapshot-index-def[]
-
-[[glossary-segment]] segment::
-// tag::segment-def[]
-Data file in a <<glossary-shard,shard>>'s Lucene instance. {es} manages Lucene
-segments automatically.
-// end::segment-def[]
-
-[[glossary-shard]] shard::
-// tag::shard-def[]
-Lucene instance containing some or all data for an <<glossary-index,index>>.
-{es} automatically creates and manages these Lucene instances. There are two
-types of shards: <<glossary-primary-shard,primary>> and
-<<glossary-replica-shard,replica>>. See {ref}/scalability.html[Clusters, nodes,
-and shards].
-// end::shard-def[]
-
-[[glossary-shrink]] shrink::
-// tag::shrink-def[]
-// tag::shrink-def-short[]
-Reduces the number of <<glossary-primary-shard,primary shards>> in an index.
-// end::shrink-def-short[]
-See the {ref}/indices-shrink-index.html[shrink index API].
-// end::shrink-def[]
-
-[[glossary-snapshot]] snapshot::
-// tag::snapshot-def[]
-Backup taken of a running <<glossary-cluster,cluster>>. You can take snapshots
-of the entire cluster or only specific <<glossary-data-stream,data streams>> and
-<<glossary-index,indices>>. See {ref}/snapshot-restore.html[Snapshot and
-restore].
-// end::snapshot-def[]
-
-[[glossary-snapshot-lifecycle-policy]] snapshot lifecycle policy::
-// tag::snapshot-lifecycle-policy-def[]
-Specifies how frequently to perform automatic backups of a cluster and how long
-to retain the resulting <<glossary-snapshot,snapshots>>. See
-{ref}/snapshot-lifecycle-management.html[Manage the snapshot lifecycle]
-// end::snapshot-lifecycle-policy-def[]
-
-[[glossary-snapshot-repository]] snapshot repository::
-// tag::snapshot-repository-def[]
-Location where <<glossary-snapshot,snapshots>> are stored. A snapshot repository
-can be a shared filesystem or a remote repository, such as Azure or Google Cloud
-Storage. See {ref}/snapshot-restore.html[Snapshot and restore].
-// end::snapshot-repository-def[]
-
-[[glossary-source_field]] source field::
-// tag::source-field-def[]
-Original JSON object provided during <<glossary-index,indexing>>. See the
-{ref}/mapping-source-field.html[`_source` field].
-// end::source-field-def[]
-
-[[glossary-split]] split::
-// tag::split-def[]
-Adds more <<glossary-primary-shard,primary shards>> to an
-<<glossary-index,index>>. See the {ref}/indices-split-index.html[split index
-API].
-// end::split-def[]
-
-[[glossary-system-index]] system index::
-// tag::system-index-def[]
-<<glossary-index,Index>> containing configurations and other data used
-internally by the {stack}. System index names start with a dot (`.`), such as
-`.security`. Do not directly access or change system indices.
-// end::system-index-def[]
-
-[[glossary-term]] term::
-// tag::term-def[]
-See {ref}/glossary.html#glossary-token[token].
-// end::term-def[]
-
-[[glossary-text]] text::
-// tag::text-def[]
-Unstructured content, such as a product description or log message. You
-typically <<glossary-analysis,analyze>> text for better search. See
-{ref}/analysis.html[Text analysis].
-// end::text-def[]
-
-[[glossary-token]] token::
-// tag::token-def[]
-A chunk of unstructured <<glossary-text,text>> that's been optimized for search.
-In most cases, tokens are individual words. Tokens are also called terms. See
-{ref}/analysis.html[Text analysis].
-// end::token-def[]
-
-[[glossary-tokenization]] tokenization::
-// tag::tokenization-def[]
-Process of breaking unstructured text down into smaller, searchable chunks
-called <<glossary-token,tokens>>. See
-{ref}/analysis-overview.html#tokenization[Tokenization].
-// end::tokenization-def[]
-
-[[glossary-warm-phase]] warm phase::
-// tag::warm-phase-def[]
-Second possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In
-the warm phase, an <<glossary-index,index>> is generally optimized for search
-and no longer updated. See {ref}/ilm-policy-definition.html[Index lifecycle].
-// end::warm-phase-def[]
-
-[[glossary-warm-tier]] warm tier::
-// tag::warm-tier-def[]
-<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that hold
-time series data that is accessed less frequently and rarely needs to be
-updated. See {ref}/data-tiers.html[Data tiers].
-// end::warm-tier-def[]

docs/reference/how-to/search-speed.asciidoc

@@ -356,7 +356,7 @@ There are multiple caches that can help with search performance, such as the
 {wikipedia}/Page_cache[filesystem cache], the
 <<shard-request-cache,request cache>> or the <<query-cache,query cache>>. Yet
 all these caches are maintained at the node level, meaning that if you run the
-same request twice in a row, have 1 <<glossary-replica-shard,replica>> or more
+same request twice in a row, have 1 replica or more
 and use {wikipedia}/Round-robin_DNS[round-robin], the default
 routing algorithm, then those two requests will go to different shard copies,
 preventing node-level caches from helping.

docs/reference/ilm/example-index-lifecycle-policy.asciidoc

@@ -29,7 +29,7 @@ the data. This data has the following retention requirements:
 * After rollover, keep indices in the hot data tier for 30 days.
 * 30 days after rollover:
 ** Move indices to the warm data tier.
-** Set <<glossary-replica-shard, replica shards>> to 1.
+** Set replica shards to 1.
 ** <<indices-forcemerge, Force merge>> multiple index segments to free up the
 space used by deleted documents.
 * Delete indices 90 days after rollover.

docs/reference/ilm/ilm-overview.asciidoc

@@ -12,14 +12,14 @@ according to your performance, resiliency, and retention requirements.
 
 Index lifecycle policies can trigger actions such as:
 
-* **Rollover**: 
-include::../glossary.asciidoc[tag=rollover-def-short]
-* **Shrink**: 
-include::../glossary.asciidoc[tag=shrink-def-short]
-* **Force merge**: 
-include::../glossary.asciidoc[tag=force-merge-def-short]
+* **Rollover**: Creates a new write index when the current one reaches a certain
+size, number of docs, or age.
+* **Shrink**: Reduces the number of primary shards in an index.
+* **Force merge**: Triggers a <<indices-forcemerge,force merge>> to reduce the
+number of segments in an index's shards.
 * **Freeze**: <<freeze-index-api, Freezes>> an index and makes it read-only.
-* **Delete**: Permanently remove an index, including all of its data and metadata.
+* **Delete**: Permanently remove an index, including all of its data and
+metadata.
 
 {ilm-init} makes it easier to manage indices in hot-warm-cold architectures,
 which are common when you're working with time series data such as logs and metrics.

docs/reference/index.asciidoc

@@ -69,8 +69,6 @@ include::commands/index.asciidoc[]
 
 include::how-to.asciidoc[]
 
-include::glossary.asciidoc[]
-
 include::rest-api/index.asciidoc[]
 
 include::migration/index.asciidoc[]

docs/reference/indices/recovery.asciidoc

@@ -46,7 +46,7 @@ Recovery automatically occurs during the following processes:
 
 * Node startup or failure. This type of recovery is called a local store
   recovery.
-* <<glossary-replica-shard,Primary shard replication>>.
+* Primary shard replication.
 * Relocation of a shard to a different node in the same cluster.
 * <<snapshots-restore-snapshot,Snapshot restoration>>.
 
@@ -94,8 +94,7 @@ The recovery is related to
 a <<snapshots-restore-snapshot,snapshot restoration>>.
 
 `REPLICA`::
-The recovery is related to
-a <<glossary-replica-shard,primary shard replication>>.
+The recovery is related to a primary shard replication.
 
 `RELOCATING`::
 The recovery is related to

docs/reference/redirects.asciidoc

@@ -1593,3 +1593,8 @@ include::redirects.asciidoc[tag=frozen-index-redirect]
 === Monitoring frozen indices
 
 include::redirects.asciidoc[tag=frozen-index-redirect]
+
+[role="exclude",id="glossary"]
+=== Glossary
+
+See the {glossary}/terms.html[Elastic glossary].