anchor.diff:  // TESTRESPONSE[s/"transport_address" : "[^"]*"/"transport_address" : $body.$_path/]
   // TESTRESPONSE[s/"node_attributes" : \{\}/"node_attributes" : $body.$_path/]
   
  -<1> The current state of the shard
  -<2> The reason for the shard originally becoming unassigned
  -<3> Whether to allocate the shard
  -<4> Whether to allocate the shard to the particular node
  -<5> The decider which led to the `no` decision for the node
  -<6> An explanation as to why the decider returned a `no` decision, with a helpful hint pointing to the setting that led to the decision
  -
  -You can return information gathered by the cluster info service about disk usage
  -and shard sizes by setting the `include_disk_info` parameter to `true`:
  -
  -[source,js]
  ---------------------------------------------------
  -GET /_cluster/allocation/explain?include_disk_info=true
  ---------------------------------------------------
  -// CONSOLE
  -
  -Additionally, if you would like to include all decisions that were factored into the final
  -decision, the `include_yes_decisions` parameter will return all decisions for each node:
  -
  -[source,js]
  ---------------------------------------------------
  -GET /_cluster/allocation/explain?include_yes_decisions=true
  ---------------------------------------------------
  -// CONSOLE
  -
  -The default value for `include_yes_decisions` is `false`, which will only
  -include the `no` decisions in the response.  This is generally what you would
  -want, as the `no` decisions indicate why a shard is unassigned or cannot be moved,
  -and including all decisions include the `yes` ones adds a lot of verbosity to the
  -API's response output.
  +<1> The current state of the shard.
  +<2> The reason for the shard originally becoming unassigned.
  +<3> Whether to allocate the shard.
  +<4> Whether to allocate the shard to the particular node.
  +<5> The decider which led to the `no` decision for the node.
  +<6> An explanation as to why the decider returned a `no` decision, with a helpful hint pointing to the setting that led to the decision.
  +
   
   The API response output for an unassigned primary shard that had previously been
   allocated to a node in the cluster:
  
positive.code: // TEST[skip:no way of knowing the current_node]
  <1> The node where shard 0 currently has a replica on
  
  You can also have Elasticsearch explain the allocation of the first unassigned
  shard that it finds by sending an empty body for the request:
  
  [source,js]
  --------------------------------------------------
  GET /_cluster/allocation/explain
  --------------------------------------------------
  // CONSOLE
  
  [float]
  ==== Explain API Response
  
  This section includes examples of the cluster allocation explain API response output
  under various scenarios.
  
  //////////////////////////
  
  [source,js]
  --------------------------------------------------
  
negative.code: }
  --------------------------------------------------
  // NOTCONSOLE
  <1> Whether rebalancing is allowed on the cluster.
  <2> Whether the shard can be rebalanced to another node.
  <3> The reason the shard cannot be rebalanced to the node, in this case indicating that it offers no better balance than the current node.
  