anchor.diff:  `kudu`.
   
   ==== Prepare for the recovery
  +
  +. If the deployment was configured without DNS aliases perform the following steps:
  +* Establish a maintenance window (one hour should be sufficient). During this time the Kudu cluster
  +  will be unavailable.
  +* Shut down all Kudu tablet server processes in the cluster.
   
   . Ensure that the dead master is well and truly dead. Take whatever steps needed to prevent it from
     accidentally restarting; this can be quite dangerous for the cluster post-recovery.
  
positive.code: 
  Due to https://issues.apache.org/jira/browse/KUDU-1620[KUDU-1620], it is not possible to perform
  this workflow without also restarting the live masters. As such, the workflow requires a
  maintenance window, albeit a brief one as masters generally restart quickly.
  
  WARNING: Kudu does not yet support Raft configuration changes for masters. As such, it is only
  possible to replace a master if the deployment was created with DNS aliases. See the
  <<migrate_to_multi_master,multi-master migration workflow>> for more details.
  
  WARNING: The workflow presupposes at least basic familiarity with Kudu configuration management. If
  using Cloudera Manager (CM), the workflow also presupposes familiarity with it.
  
negative.code:   or an alias in /etc/hosts. The alias should be an abstract representation of the master (e.g.
    `master-1`).
  +
  WARNING: Without DNS aliases it is not possible to recover from permanent master failures without
  bringing the cluster down for maintenance, and as such, it is highly recommended.
  +
  . Perform the following preparatory steps for each new master:
  * Choose an unused machine in the cluster. The master generates very little load so it can be
  