anchor.diff:  	<li>The Cloud Controller redirects the Cell's droplet download request to the blobstore.</li>
   	<li>The Diego Cell downloads the app's droplet from the blobstore and runs it.</li>
   	</ol>
  +
  +##<a id='blobstore-expiry'></a>How CC reaps expired packages, droplets, and buildpacks
  +
  +Nightly, starting at midnight, the Cloud Controller runs a series of scheduled jobs to delete the data associated with
  +expired packages, droplets, and buildpacks.
  +
  +<describe how expiry works>
  +<describe how orphans are reaped>
  +
  +Source files uploaded prior to forming packages are not deleted.
  +
  +* don't forget note about blobstore-native versioning and how that can effect costs and deletions
  +
  +##<a id='blobstore-timeouts'></a>How long CC gives the blobstore to respond to its requests
  +
  +
  
positive.code: 
  This topic references staging and treats all blobstores as generic (S3-style) object stores.
  
  For more information about staging, see [How Apps Are Staged](../concepts/how-applications-are-staged.html).
  
  For more information about how specific 3rd party blobstores can be configured, see [Cloud Controller Blobstore Configuration](../deploying/common/cc-blobstore-config.html).
  
  ##<a id='stage-buildpack'></a>How staging uses the blobstore
  
  This section describes how staging buildpack apps utilizes the blobstore.
  
  The following diagram illustrates, in-depth, how the staging process uses the blobstore:
  
  ![The staging process for buildpack apps includes a developer and the following components: CF Command Line, Cloud Controller (CCNG), Blobstore, cc-uploader, Diego Cell (Staging), and Diego Cell (Running). Step 1 is CF Push from Developer to CF Command Line. Step 2 is Hashsum source files from Developer to CF Command Line. Step 3 is Resource Match from CF Command Line to the CCNG. Step 4 is Check file existence from the CCNG to Blobstore. Step 5 is Upload unmatched files from CF Command Line to CCNG. Step 6 is Download cached files from Blobstore to CCNG. Step 7 is Upload complete package from CCNG to Blobstore. Step 8 is Download package and buildpack from Blobstore to Diego Cell (Staging). Step 9 is Upload droplet from Diego Cell (Staging) through cc-uploader, then CCNG, to the Blobstore. Step 10 is Download droplet from Blobstore to CCNG.](app_push_flow_diagram_diego.png)
  
  [//]: https://docs.google.com/drawings/d/1LbM5mRjJMOfQXVvJXmDb-csfV61kHaPJaCJy20WVqMI/edit?usp=sharing
  
  
negative.code: 
  1. A developer runs `cf push`.
  
  1. The cf CLI gets all the developers local source code files and computes a checksum of each.
  
  1. The cf CLI makes a "Resource Match" request to the cloud controller, listing those files and their checksums.
  
  1. This step, "Check file existence", includes the following:
  	<ol type="a">
    <li>The Cloud Controller makes a series of "HEAD"-type requests to the blobstore to find out which files it has cached.</li>
    <li>Cloud Controller content-addresses its cached files so that changes to a file result in it being stored as a different object.</li>
    <li>Eventually Cloud Controller is able to compute which files it has and which it needs the CLI to upload.
    <li>In environments where apps have many files, this can generate unusual load patterns on the blobstore which may cause trouble depending on its implementation.</li>
    <li>In response to the resource match request, Cloud Controller lists the files the CLI needs to upload .</li>
    </ol>
  
  1. The CLI compresses and uploads the unmatched files to the Cloud Controller.
  