anchor.diff:  
   In the manifest you specify orchestration along with everything else about your deployment,
   including the stemcell, release, and network configuration to use.
  +
  +**Note**: This topic does not treat using multiple releases or stemcells for simplicity's sake, but BOSH supports both.
   
   ## <a id="release"></a> Translating from Release to Manifest ##
   
  
positive.code: title: Create a Manifest
  ---
  
  When you discover a distributed software product that you want to deploy to the cloud using BOSH,
  you download a BOSH release of the product and locate a stemcell appropriate for your preferred combination of VM and IaaS.
  
  Next, you need to decide how to orchestrate and configure the deployment,
  and to express your decisions in a form that BOSH can consume: namely, a deployment manifest.
  This topic explains how manifests work and how to create them.
  
  ## <a id="orchestrate"></a> Specifying Orchestration ##
  
  Suppose the product you want to deploy can do five things: call these capabilities Feature A through Feature D.
  You want your deployment to take advantage of all five features, but you don't want any one VM to be responsible for more than two features.
  For the sake of capacity and resilience, you want every feature to run on more than one VM.
  
  
negative.code: * 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 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.
  
  <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:
  
  