anchor.diff:  --------------------------------------------------
   
   
  -Response in case some copies of a shard failed:
  +Here is what it looks like when one copy fails:
   
   [source,js]
   --------------------------------------------------
  
positive.code: --------------------------------------------------
  
  
  Response in case all copies of a shard failed:
  
  [source,js]
  --------------------------------------------------
  
negative.code: [[indices-seal]]
  == Seal
  
  The seal API flushes and adds a "seal" marker to the shards of one or more
  indices. The seal is used during recovery or restarts to skip the first and
  most costly phase of the process if all copies of the shard have the same seal.
  No segment files need to be copied and the transaction log replay phase of the
  recovery can start immediately which makes recovery much faster.
  
  There are two important points about seals:
  1. They are best effort in that if there are any outstanding write operations
  while the seal operation is being performed then the shards which those writes
  target won't be sealed but all others will be. See below for more.
  2. The seal breaks as soon as the shard issues a new lucene commit. Uncommitted
  operations in the transaction log do not break the seal. That is because a seal
  marks a point in time snapshot of the segments, a low level lucene commit.
  Practically that means that every write operation on the index will remove the
  seal.
  
  [source,bash]
  --------------------------------------------------
  $ curl -XPOST 'http://localhost:9200/twitter/_seal'
  --------------------------------------------------
  
  The response contains details about which shards wrote the seal and the reason
  in case they failed to write the seal.
  
  Here is what it looks like when all copies single shard index successfully
  wrote the seal:
  
  [source,js]
  --------------------------------------------------
  