Docs: Included the index-seal docs in the indices section

docs/reference/indices.asciidoc

@@ -59,6 +59,7 @@ and warmers.
 * <<indices-refresh>>
 * <<indices-flush>>
 * <<indices-optimize>>
+* <<indices-seal>>
 * <<indices-upgrade>>
 
 --
@@ -107,6 +108,9 @@ include::indices/refresh.asciidoc[]
 
 include::indices/optimize.asciidoc[]
 
-include::indices/upgrade.asciidoc[]
+include::indices/seal.asciidoc[]
 
 include::indices/shadow-replicas.asciidoc[]
+
+include::indices/upgrade.asciidoc[]
+

docs/reference/indices/seal.asciidoc

@@ -1,20 +1,31 @@
 [[indices-seal]]
 == Seal
 
-The seal API allows to flush one or more indices and adds a marker to primaries and replicas if there are no pending write operations.
+The seal API allows to flush one or more indices and adds a marker to
-The seal marker is used during recovery after a node restarts. If a replica is allocated on a node which already has a shard copy with the same seal as the primary then no files will be copied during recovery.
+primaries and replicas if there are no pending write operations. The seal
-Sealing is a best effort operation. If write operations are ongoing while the sealing is in progress then writing the seal might fail on some copies.
+marker is used during recovery after a node restarts. If a replica is
+allocated on a node which already has a shard copy with the same seal as the
+primary then no files will be copied during recovery. Sealing is a best effort
+operation. If write operations are ongoing while the sealing is in progress
+then writing the seal might fail on some copies.
 
-A seal marks a point in time snapshot (a low level lucene commit). This mark can be used to decide if the initial, rather resource heavy, recovery phase where segments or event the entire lucene index is copied over the network can
+A seal marks a point in time snapshot (a low level Lucene commit). This mark
-be skipped. If the indices on both sides of the recover have the same seal no segment files need to be copied and transaction log replay can start immediately. The seal breaks as soon as the shard issues a new lucene commit, uncommitted operations
+can be used to decide if the initial, rather resource heavy, recovery phase
-in the transaction log do not break the seal until they are committed.
+where segments or event the entire lucene index is copied over the network can
+be skipped. If the indices on both sides of the recovery have the same seal no
+segment files need to be copied and transaction log replay can start
+immediately. The seal breaks as soon as the shard issues a new lucene commit,
+uncommitted operations in the transaction log do not break the seal until they
+are committed.
 
 [source,js]
 --------------------------------------------------
-$ curl -XPOST 'http://localhost:9200/twitter/_seal'
+curl -XPOST 'http://localhost:9200/twitter/_seal'
 --------------------------------------------------
 
-The response contains details about for which shards a seal was written and the reason in case of failure.
+The response contains details about for which shards a seal was written and
+the reason in case of failure.
+
 Response in case all copies of a shard successfully wrote the seal:
 
 [source,js]
@@ -34,6 +45,7 @@ Response in case all copies of a shard successfully wrote the seal:
 
 
 Response in case some copies of a shard failed:
+
 [source,js]
 --------------------------------------------------
 {
@@ -51,6 +63,7 @@ Response in case some copies of a shard failed:
 
 
 Response in case all copies of a shard failed:
+
 [source,js]
 --------------------------------------------------
 {
@@ -72,7 +85,7 @@ or even on `_all` the indices.
 
 [source,js]
 --------------------------------------------------
-$ curl -XPOST 'http://localhost:9200/kimchy,elasticsearch/_seal'
+curl -XPOST 'http://localhost:9200/kimchy,elasticsearch/_seal'
 
-$ curl -XPOST 'http://localhost:9200/_seal'
+curl -XPOST 'http://localhost:9200/_seal'
 --------------------------------------------------