anchor.diff:  * 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.
  +and monitors the 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_
  +
  +<pre class="terminal">
  +update:
  +  canaries: 1
  +  canary_watch_time: 30000-240000
  +  update_watch_time: 30000-600000
  +  max_in_flight: 3
  +</pre>
   
   ### <a id='resource_pools'></a> The resource_pools block ###
  +
  +IaaS-dependent instance type
   
   Resource pools are collections of VMs which are on the same network, are the same kind of VM from the IaaS's perspective, and are built from the same stemcell.
   The `resource_pools` block specifies all of these.
   
  +<pre class="terminal">
  +resource_pools:
  +- name: default
  +  stemcell:
  +    name: bosh-aws-xen-ubuntu
  +    version: latest
  +  network: default
  +  size: 1
  +  cloud_properties:
  +    instance_type: m1.small
  +    availability_zone: us-east-1c
  +</pre>
  +
   ### <a id='networks'></a> The networks block ###
  +
  +IaaS-dependent -- some have subnet, some have network names, some keys differ
   
   The `networks` block is where you specify network configuration information for the deployment.
   Networks are named, enabling you to specify multiple networks.
   
  +<pre class="terminal">
  +networks:
  +- name: default
  +  type: manual
  +  subnets:
  +  - range: 10.10.0.0/24
  +    gateway: 10.10.0.1
  +    static:
  +    - 10.10.0.7 - 10.10.0.9
  +    reserved:
  +    - 10.10.0.2 - 10.10.0.6
  +    - 10.10.0.10 - 10.10.0.10
  +    dns:
  +    - 10.10.0.6
  +    cloud_properties:
  +      subnet: subnet-d597b993
  +</pre>
  +
   ### <a id='jobs'></a> The jobs block ###
  +
  +IaaS-agnostic
  +
   
   The `jobs` block is where you name VM types and specify:
   
  
positive.code: 1. jobs
  1. properties
  
  Manifests are written in YAML, which means that each block is translated into a hash.
  You can put the blocks in any order.
  
  ### <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:
  
negative.code:     default: [dns, gateway]
  </pre>
  
  ## <a id="anatomy"></a> Anatomy of a Manifest ##
  
  Parts of any given BOSH manifest are IaaS-specific.
  Most manifest content, though, is independent of the cloud infrastructure where you want to deploy.
  This allows you to re-use manifests, making minimal changes, even when moving a deployment from one IaaS to another.
  
  A BOSH deployment manifest begins with three dashes, and then identifies the deployment as follows:
  
  1. The **name** you give the deployment.
  1. The `director_uuid` to ensure that you deploy with the correct BOSH.
  
  For example:
  
  