anchor.diff:  
   ## <a id="anatomy"></a> Anatomy of a Manifest ##
   
  -A BOSH deployment manifest begins by identifying the deployment.
  +Some of the information in any given BOSH manifest is IaaS-specific.
  +The vast majority of manifest content, though, is independent of the cloud infrastructure where you want to deploy.
  +This makes it possible to re-use manifests, making minimal changes, even when moving a deployment from one IaaS to another.
  +
  +A BOSH deployment manifest begins by identifying the deployment as follows:
  +
  +1. The **name** you give the deployment.
  +1. The `director_uuid` _insert text here_ to ensure that you deploy with the correct BOSH.
  +1. The **release name** you choose.
  +1. The **release version** which _insert description here_.
   
   For example:
   
  
positive.code: The `properties` block consists of headings which are the names of features (templates) from the `jobs` block.
  Each heading is followed by one or more lines of configuration information.
  
  
negative.code: ### <a id='compilation'></a> The compilation block ###
  
  BOSH compiles all the software packages within the release at deploy time.
  The `compilation` block specifies which VMs should perform the compilation.
  
  ### <a id='update'></a> The update block ###
  
  The `update` block:
  
  * Uses the `max_in_flight` variable to limit the number of VMs that can be updated simultaneously.
  * Specifies the number and desired behavior of "canaries."
  
  Before BOSH updates all the instances of a given VM type, it updates one or more "canaries,"
  and monitors to update to determine whether it can run successfully on that VM type.
  
  A "canary" is just an instance of the VM type to be updated.
  
  If the "canary" update fails, or even appears to succeed too quickly, BOSH does not proceed to update the rest of the instances.
  _maybe insert more explanation here_
  
  ### <a id='resource_pools'></a> The resource_pools block ###
  
  