anchor.diff:  
   The Rolling strategy will:
   
  -. Execute any "pre" lifecycle hook.
  +. Execute any `*pre*` lifecycle hook.
   . Scale up the new deployment based on the surge configuration.
   . Scale down the old deployment based on the max unavailable configuration.
   . Repeat this scaling until the new deployment has reached the desired replica
   count and the old deployment has been scaled to zero.
  -. Execute any "post" lifecycle hook.
  -
  -IMPORTANT: When scaling down, the rolling strategy waits for pods to become
  -ready so it can decide whether further scaling would affect availability. If
  -scaled up pods never become ready, the deployment will eventually time out and
  -result in a deployment failure.
  -
  -IMPORTANT: When executing the "post" lifecycle hook, all failures will be
  -ignored regardless of the failure policy specified on the hook.
  -
  -`*maxUnavailable*` is the maximum number of pods that can be unavailable
  -during the update.
  -
  -`*maxSurge*` is the maximum number of pods that can be scheduled above the
  -original number of pods.
  -
  -Both fields can be either a percentage (e.g.  `10%`) or an absolute value
  -(e.g. `2`). The default value for both is `25%`.
  -
  -These fields allow the deployment to be tuned for availability and speed. For
  +. Execute any `*post*` lifecycle hook.
  +
  +[IMPORTANT]
  +====
  +When scaling down, the Rolling strategy waits for pods to become ready so it can
  +decide whether further scaling would affect availability. If scaled up pods
  +never become ready, the deployment will eventually time out and result in a
  +deployment failure.
  +====
  +
  +[IMPORTANT]
  +====
  +When executing the `*post*` lifecycle hook, all failures will be ignored
  +regardless of the failure policy specified on the hook.
  +====
  +
  +The `*maxUnavailable*` parameter is the maximum number of pods that can be
  +unavailable during the update. The `*maxSurge*` parameter is the maximum number
  +of pods that can be scheduled above the original number of pods. Both parameters
  +can be set to either a percentage (e.g.,  *10%*) or an absolute value (e.g.,
  +*2*). The default value for both is *25%*.
  +
  +These parameters allow the deployment to be tuned for availability and speed. For
   example:
   
  -* `*maxUnavailable*=0` and `*maxSurge*=20%` would ensure full capacity is
  -maintained during the update and rapid scale up.
  -* `*maxUnavailable*=10%` and `*maxSurge*=0` would perform an update using no
  -extra capacity (an in-place update).
  -* `*maxUnavailable*=10%` and `*maxSurge*=10%` would scale up and down quickly
  -with some potential for capacity loss.
  +- `*maxUnavailable*=0` and `*maxSurge*=20%` ensures full capacity is maintained
  +during the update and rapid scale up.
  +- `*maxUnavailable*=10%` and `*maxSurge*=0` performs an update using no extra
  +capacity (an in-place update).
  +- `*maxUnavailable*=10%` and `*maxSurge*=10%` scales up and down quickly with
  +some potential for capacity loss.
   
   [[recreate-strategy]]
   
  
positive.code:   }
  }
  ----
  
  <1> How long to wait for a scaling event before giving up. Optional; the default is 120.
  <2> `*maxSurge*` is optional and defaults to `25%`; see below.
  
negative.code: 
  The following is an example of the Rolling strategy:
  
  ====
  [source,json]
  ----
  "strategy": {
  