[DOCS] Fix indentation in glossary for Asciidoctor migration (#42118)

Author: jrodewig

docs/reference/glossary.asciidoc

@@ -5,186 +5,186 @@
 [glossary]
 [[glossary-analysis]] analysis ::
 
-  Analysis is the process of converting <<glossary-text,full text>> to
-  <<glossary-term,terms>>. Depending on which analyzer is used, these phrases:
-  `FOO BAR`, `Foo-Bar`, `foo,bar` will probably all result in the
-  terms `foo` and `bar`. These terms are what is actually stored in
-  the index.
-  +
-  A full text query (not a <<glossary-term,term>> query) for `FoO:bAR` will
-  also be analyzed to the terms `foo`,`bar` and will thus match the
-  terms stored in the index.
-  +
-  It is this process of analysis (both at index time and at search time)
-  that allows elasticsearch to perform full text queries.
-  +
-  Also see <<glossary-text,text>> and <<glossary-term,term>>.
+Analysis is the process of converting <<glossary-text,full text>> to
+<<glossary-term,terms>>. Depending on which analyzer is used, these phrases:
+`FOO BAR`, `Foo-Bar`, `foo,bar` will probably all result in the
+terms `foo` and `bar`. These terms are what is actually stored in
+the index.
++
+A full text query (not a <<glossary-term,term>> query) for `FoO:bAR` will
+also be analyzed to the terms `foo`,`bar` and will thus match the
+terms stored in the index.
++
+It is this process of analysis (both at index time and at search time)
+that allows elasticsearch to perform full text queries.
++
+Also see <<glossary-text,text>> and <<glossary-term,term>>.
 
 [[glossary-cluster]] cluster ::
 
-  A cluster consists of one or more <<glossary-node,nodes>> which share the
-  same cluster name. Each cluster has a single master node which is
-  chosen automatically by the cluster and which can be replaced if the
-  current master node fails.
+A cluster consists of one or more <<glossary-node,nodes>> which share the
+same cluster name. Each cluster has a single master node which is
+chosen automatically by the cluster and which can be replaced if the
+current master node fails.
 
 [[glossary-document]] document ::
 
-  A document is a JSON document which is stored in elasticsearch. It is
-  like a row in a table in a relational database. Each document is
-  stored in an <<glossary-index,index>> and has a <<glossary-type,type>> and an
-  <<glossary-id,id>>.
-  +
-  A document is a JSON object (also known in other languages as a hash /
-  hashmap / associative array) which contains zero or more
-  <<glossary-field,fields>>, or key-value pairs.
-  +
-  The original JSON document that is indexed will be stored in the
-  <<glossary-source_field,`_source` field>>, which is returned by default when
-  getting or searching for a document.
+A document is a JSON document which is stored in elasticsearch. It is
+like a row in a table in a relational database. Each document is
+stored in an <<glossary-index,index>> and has a <<glossary-type,type>> and an
+<<glossary-id,id>>.
++
+A document is a JSON object (also known in other languages as a hash /
+hashmap / associative array) which contains zero or more
+<<glossary-field,fields>>, or key-value pairs.
++
+The original JSON document that is indexed will be stored in the
+<<glossary-source_field,`_source` field>>, which is returned by default when
+getting or searching for a document.
 
 [[glossary-id]] id ::
 
-  The ID of a <<glossary-document,document>> identifies a document. The
-  `index/type/id` of a document must be unique. If no ID is provided,
-  then it will be auto-generated. (also see <<glossary-routing,routing>>)
+The ID of a <<glossary-document,document>> identifies a document. The
+`index/type/id` of a document must be unique. If no ID is provided,
+then it will be auto-generated. (also see <<glossary-routing,routing>>)
 
 [[glossary-field]] field ::
 
-  A <<glossary-document,document>> contains a list of fields, or key-value
-  pairs. The value can be a simple (scalar) value (eg a string, integer,
-  date), or a nested structure like an array or an object. A field is
-  similar to a column in a table in a relational database.
-  +
-  The <<glossary-mapping,mapping>> for each field has a field _type_ (not to
-  be confused with document <<glossary-type,type>>) which indicates the type
-  of data that can be stored in that field, eg `integer`, `string`,
-  `object`. The mapping also allows you to define (amongst other things)
-  how the value for a field should be analyzed.
+A <<glossary-document,document>> contains a list of fields, or key-value
+pairs. The value can be a simple (scalar) value (eg a string, integer,
+date), or a nested structure like an array or an object. A field is
+similar to a column in a table in a relational database.
++
+The <<glossary-mapping,mapping>> for each field has a field _type_ (not to
+be confused with document <<glossary-type,type>>) which indicates the type
+of data that can be stored in that field, eg `integer`, `string`,
+`object`. The mapping also allows you to define (amongst other things)
+how the value for a field should be analyzed.
 
 [[glossary-index]] index ::
 
-  An index is like a _database_ in a relational database. It has a
-  <<glossary-mapping,mapping>> which defines multiple <<glossary-type,types>>.
-  +
-  An index is a logical namespace which maps to one or more
-  <<glossary-primary-shard,primary shards>> and can have zero or more
-  <<glossary-replica-shard,replica shards>>.
+An index is like a _database_ in a relational database. It has a
+<<glossary-mapping,mapping>> which defines multiple <<glossary-type,types>>.
++
+An index is a logical namespace which maps to one or more
+<<glossary-primary-shard,primary shards>> and can have zero or more
+<<glossary-replica-shard,replica shards>>.
 
 [[glossary-mapping]] mapping ::
 
-  A mapping is like a _schema definition_ in a relational database. Each
-  <<glossary-index,index>> has a mapping, which defines each <<glossary-type,type>>
-  within the index, plus a number of index-wide settings.
-  +
-  A mapping can either be defined explicitly, or it will be generated
-  automatically when a document is indexed.
+A mapping is like a _schema definition_ in a relational database. Each
+<<glossary-index,index>> has a mapping, which defines each <<glossary-type,type>>
+within the index, plus a number of index-wide settings.
++
+A mapping can either be defined explicitly, or it will be generated
+automatically when a document is indexed.
 
 [[glossary-node]] node ::
 
-  A node is a running instance of elasticsearch which belongs to a
-  <<glossary-cluster,cluster>>. Multiple nodes can be started on a single
-  server for testing purposes, but usually you should have one node per
-  server.
-  +
-  At startup, a node will use unicast (or multicast, if specified) to
-  discover an existing cluster with the same cluster name and will try
-  to join that cluster.
-
- [[glossary-primary-shard]] primary shard ::
-
-  Each document is stored in a single primary <<glossary-shard,shard>>. When
-  you index a document, it is indexed first on the primary shard, then
-  on all <<glossary-replica-shard,replicas>> of the primary shard.
-  +
-  By default, an <<glossary-index,index>> has 5 primary shards. You can
-  specify fewer or more primary shards to scale the number of
-  <<glossary-document,documents>> that your index can handle.
-  +
-  You cannot change the number of primary shards in an index, once the
-  index is created.
-  +
-  See also <<glossary-routing,routing>>
-
- [[glossary-replica-shard]] replica shard ::
-
-  Each <<glossary-primary-shard,primary shard>> can have zero or more
-  replicas. A replica is a copy of the primary shard, and has two
-  purposes:
-  +
-  1.  increase failover: a replica shard can be promoted to a primary
-  shard if the primary fails
-  2.  increase performance: get and search requests can be handled by
-  primary or replica shards.
-  +
-  By default, each primary shard has one replica, but the number of
-  replicas can be changed dynamically on an existing index. A replica
-  shard will never be started on the same node as its primary shard.
+A node is a running instance of elasticsearch which belongs to a
+<<glossary-cluster,cluster>>. Multiple nodes can be started on a single
+server for testing purposes, but usually you should have one node per
+server.
++
+At startup, a node will use unicast (or multicast, if specified) to
+discover an existing cluster with the same cluster name and will try
+to join that cluster.
+
+[[glossary-primary-shard]] primary shard ::
+
+Each document is stored in a single primary <<glossary-shard,shard>>. When
+you index a document, it is indexed first on the primary shard, then
+on all <<glossary-replica-shard,replicas>> of the primary shard.
++
+By default, an <<glossary-index,index>> has 5 primary shards. You can
+specify fewer or more primary shards to scale the number of
+<<glossary-document,documents>> that your index can handle.
++
+You cannot change the number of primary shards in an index, once the
+index is created.
++
+See also <<glossary-routing,routing>>
+
+[[glossary-replica-shard]] replica shard ::
+
+Each <<glossary-primary-shard,primary shard>> can have zero or more
+replicas. A replica is a copy of the primary shard, and has two
+purposes:
++
+1.  increase failover: a replica shard can be promoted to a primary
+shard if the primary fails
+2.  increase performance: get and search requests can be handled by
+primary or replica shards.
++
+By default, each primary shard has one replica, but the number of
+replicas can be changed dynamically on an existing index. A replica
+shard will never be started on the same node as its primary shard.
 
 [[glossary-routing]] routing ::
 
-  When you index a document, it is stored on a single
-  <<glossary-primary-shard,primary shard>>. That shard is chosen by hashing
-  the `routing` value. By default, the `routing` value is derived from
-  the ID of the document or, if the document has a specified parent
-  document, from the ID of the parent document (to ensure that child and
-  parent documents are stored on the same shard).
-  +
-  This value can be overridden by specifying a `routing` value at index
-  time, or a <<mapping-routing-field,routing
-  field>> in the <<glossary-mapping,mapping>>.
+When you index a document, it is stored on a single
+<<glossary-primary-shard,primary shard>>. That shard is chosen by hashing
+the `routing` value. By default, the `routing` value is derived from
+the ID of the document or, if the document has a specified parent
+document, from the ID of the parent document (to ensure that child and
+parent documents are stored on the same shard).
++
+This value can be overridden by specifying a `routing` value at index
+time, or a <<mapping-routing-field,routing
+field>> in the <<glossary-mapping,mapping>>.
 
 [[glossary-shard]] shard ::
 
-  A shard is a single Lucene instance. It is a low-level “worker” unit
-  which is managed automatically by elasticsearch. An index is a logical
-  namespace which points to <<glossary-primary-shard,primary>> and
-  <<glossary-replica-shard,replica>> shards.
-  +
-  Other than defining the number of primary and replica shards that an
-  index should have, you never need to refer to shards directly.
-  Instead, your code should deal only with an index.
-  +
-  Elasticsearch distributes shards amongst all <<glossary-node,nodes>> in the
-  <<glossary-cluster,cluster>>, and can move shards automatically from one
-  node to another in the case of node failure, or the addition of new
-  nodes.
+A shard is a single Lucene instance. It is a low-level “worker” unit
+which is managed automatically by elasticsearch. An index is a logical
+namespace which points to <<glossary-primary-shard,primary>> and
+<<glossary-replica-shard,replica>> shards.
++
+Other than defining the number of primary and replica shards that an
+index should have, you never need to refer to shards directly.
+Instead, your code should deal only with an index.
++
+Elasticsearch distributes shards amongst all <<glossary-node,nodes>> in the
+<<glossary-cluster,cluster>>, and can move shards automatically from one
+node to another in the case of node failure, or the addition of new
+nodes.
 
  [[glossary-source_field]] source field ::
 
-  By default, the JSON document that you index will be stored in the
-  `_source` field and will be returned by all get and search requests.
-  This allows you access to the original object directly from search
-  results, rather than requiring a second step to retrieve the object
-  from an ID.
-  +
-  Note: the exact JSON string that you indexed will be returned to you,
-  even if it contains invalid JSON. The contents of this field do not
-  indicate anything about how the data in the object has been indexed.
+By default, the JSON document that you index will be stored in the
+`_source` field and will be returned by all get and search requests.
+This allows you access to the original object directly from search
+results, rather than requiring a second step to retrieve the object
+from an ID.
++
+Note: the exact JSON string that you indexed will be returned to you,
+even if it contains invalid JSON. The contents of this field do not
+indicate anything about how the data in the object has been indexed.
 
 [[glossary-term]] term ::
 
-  A term is an exact value that is indexed in elasticsearch. The terms
-  `foo`, `Foo`, `FOO` are NOT equivalent. Terms (i.e. exact values) can
-  be searched for using _term_ queries. +
-   See also <<glossary-text,text>> and <<glossary-analysis,analysis>>.
+A term is an exact value that is indexed in elasticsearch. The terms
+`foo`, `Foo`, `FOO` are NOT equivalent. Terms (i.e. exact values) can
+be searched for using _term_ queries. +
+See also <<glossary-text,text>> and <<glossary-analysis,analysis>>.
 
 [[glossary-text]] text ::
 
-  Text (or full text) is ordinary unstructured text, such as this
-  paragraph. By default, text will be <<glossary-analysis,analyzed>> into
-  <<glossary-term,terms>>, which is what is actually stored in the index.
-  +
-  Text <<glossary-field,fields>> need to be analyzed at index time in order to
-  be searchable as full text, and keywords in full text queries must be
-  analyzed at search time to produce (and search for) the same terms
-  that were generated at index time.
-  +
-  See also <<glossary-term,term>> and <<glossary-analysis,analysis>>.
+Text (or full text) is ordinary unstructured text, such as this
+paragraph. By default, text will be <<glossary-analysis,analyzed>> into
+<<glossary-term,terms>>, which is what is actually stored in the index.
++
+Text <<glossary-field,fields>> need to be analyzed at index time in order to
+be searchable as full text, and keywords in full text queries must be
+analyzed at search time to produce (and search for) the same terms
+that were generated at index time.
++
+See also <<glossary-term,term>> and <<glossary-analysis,analysis>>.
 
 [[glossary-type]] type ::
 
-  A type is like a _table_ in a relational database. Each type has a
-  list of <<glossary-field,fields>> that can be specified for
-  <<glossary-document,documents>> of that type. The <<glossary-mapping,mapping>>
-  defines how each field in the document is analyzed.
+A type is like a _table_ in a relational database. Each type has a
+list of <<glossary-field,fields>> that can be specified for
+<<glossary-document,documents>> of that type. The <<glossary-mapping,mapping>>
+defines how each field in the document is analyzed.