anchor.diff:  
   This block is IaaS-dependent, because subnets, network names, and other keys may differ from IaaS to IaaS.
   
  -### <a id='jobs'></a> The jobs block ###
  +### <a id='resources'></a> The resources block ###
   
  -The `jobs` block is where you name VM types and specify:
  -
  -* The product features each type supports, in the form of templates.
  -* Some configuration information that applies to the VM type as opposed to the feature.
  -
  -Features (templates) typically require configuration.
  -You specify this information in the `properties` block.
  -
  -For example:
  +The resources block lists
   
   <pre class="terminal">
  -jobs:
  -- name: dummy
  -  templates:
  -  - name: dummy
  -    release: dummy_a
  -  instances: 1
  -  resource_pool: default
  -  persistent_disk: 10240
  -  networks:
  -  - name: default
  +resources:
  +
   </pre>
   
  -This block is IaaS-agnostic.
  +### <a id='cloud'></a> The cloud block ###
   
  -### <a id='properties'></a> The properties block ###
  +
  +### <a id='apply'></a> The apply_spec block ###
   
   The `properties` block consists of headings followed by one or more lines of configuration information.
   Most headings are names of features (templates) from the `jobs` block.
  
positive.code: * [OpenStack](./micro-manifest-examples/openstack-example.html)
  * [vSphere](./micro-manifest-examples/vsphere-example.html)
  
  _Adapt this BOSH text to MicroBOSH_
  
  ## <a id="orchestrate"></a> Specifying Orchestration ##
  
  Suppose the product you want to deploy can do five things: call these capabilities Feature A through Feature E.
  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.
  
  To achieve this, you define VM types, where each type supports different features.
  Then you decide how many instances of each VM type to create. Now how have orchestrated your deployment.
  
  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 ##
  
  
  ## <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 with minimal changes, even you re-deploy on a different IaaS.
  
  You begin the BOSH deployment manifest with three dashes, followed by the name you give the deployment,
  then a `director_uuid` that ensures that you deploy with the correct BOSH.
  
  For example:
  
  <pre class="terminal">
  ---
  name: dummy
  director_uuid: 080a8261-8bf8-4996-a754-2545a99c0b2c
  </pre>
  
  After that, the manifest has seven required _blocks_:
  
  1. `releases`
  1. `compilation`
  1. `update`
  1. `resource_pools`
  1. `networks`
  1. `jobs`
  1. `properties`
  
  The manifest is in YAML, so the YAML parser translates each block into a hash.
  For this reason, you can put the blocks in any order.
  
  ### <a id='releases'></a> The releases block ###
  
  The release block lists the name and version of each release you use in your deployment:
  
  For example:
  
  <pre class="terminal">
  releases:
  - name: foo_beta
    version: 0.1-dev
  </pre>
  
  This block is IaaS-agnostic.
  
  ### <a id='compilation'></a> The compilation block ###
  
  At deploy time, BOSH compiles all the software packages within the release.
  The `compilation` block specifies which VMs should perform the compilation.
  
  For example:
  
  <pre class="terminal">
  compilation:
    reuse_compilation_vms: true
    workers: 2
    network: default
    cloud_properties:
      instance_type: c1.medium
      availability_zone: us-east-1c
  </pre>
  
  This block contains an IaaS-dependent `cloud_properties` sub-block.
  
  ### <a id='update'></a> The update block ###
  
  The `update` block specifies:
  
  * The maximum number of VMs that can be updated simultaneously, with the `max_in_flight` key.
  * The number of "canaries" with the `canaries` key.
  * The update behavior of "canaries" with the `canary_watch_time` key.
  * The update behavior of VMs that are _not_ "canaries" with the `update_watch_time` key.
  
  A "canary" is just an instance of the VM type to be updated.
  BOSH updates the canaries first, and only goes on to update the remaining VMs once the canaries have updated successfully.
  You use canaries to determine whether an update can run successfully on that VM type.
  A common use case is that when a deployment contains many VMs, it makes sense to test a new release on a few of them
  before trying to update the entire cohort.
  
  Update behavior is based on the concept of _watch time_, whose minimum and maximum you specify in milliseconds.
  Watch time works like this:
  
  * Between the moment update begins and the minimum is reached, BOSH reacts if the update fails
  but otherwise makes no effort to learn the state of the VM being updated.
  * Between the minimum and maximum, BOSH checks the health of the VM at intervals.
  * If the update fails at any time, BOSH ends the update with the error message "job is not running."
  * If the the last canary to update completes its update successfully,
  BOSH goes on to update the remaining VMs without waiting for the maximum watch time.
  * If the the last VM that is not a canary completes its update successfully,
  BOSH declares the update complete without waiting for the maximum watch time.
  * BOSH ends the update with an error at the maximum watch time if one or more VMs (canaries or not) have not completed their updates. ("One or more" is the default threshold.)
  
  In the example below:
  
  * There are three canaries, with a minimum watch time of 30 seconds and a maximum watch time of four minutes.
  * VMs that are not canaries can update ten at a time, with a minimum watch time of 30 seconds and a maximum watch time of ten minutes.
  
  <pre class="terminal">
  update:
    canaries: 3
    canary_watch_time: 30000-240000
    update_watch_time: 30000-600000
    max_in_flight: 10
  </pre>
  
  This block is IaaS-agnostic.
  
  ### <a id='resource_pools'></a> The resource_pools block ###
  
  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.
  
  For example:
  
  <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>
  
  This block contains an IaaS-dependent `cloud_properties` sub-block.
  
  ### <a id='networks'></a> The networks block ###
  
  The `networks` block is where you specify network configuration information for the deployment.
  You can specify multiple networks.
  
negative.code: title: Creating a MicroBOSH Deployment Manifest
  ---
  
  The deployment manifest for MicroBOSH is similar the deployment manifest for multi-VM BOSH,
  but much smaller.
  
  Parts of the manifest are IaaS-specific.
  