anchor.diff:  
   The Auction package encodes the behavioral details around the [auction](./diego-auction.html).
   
  -It includes a simulation test suite that validates the correctness and performance of the auction algorithm.  The simulation can be run for different algorithms, at different scales.  The simulation can either be run in-process (for quick feedback loops) or across multiple processes (to understand the role of communication in the auction) or even across multiple machines in a cloud-like infrastructure (to understand the impact of latency on the auction).
  +It includes a simulation test suite that validates the optimality and performance of the auction algorithm.  The simulation can be run for different algorithm variants at different scales.  The simulation can be run in several ways: 
  +- In-process, for quick feedback loops
  +- Across multiple processes, to reveal the role of communication in the auction
  +- Across multiple machines in a cloud-like infrastructure, to reveal the impact of latency on the auction
   
   The [Auctioneer](./diego-pedia.html#auctioneer) and [Rep](./diego-pedia.html#rep) components use the Auction package to participate in the [auction](./diego-auction.html).
   
  
positive.code: 
  - Running LRP instances
  
  - Inflight Tasks
  
  The [Converger](./diego-pedia.html#converger) operates on the BBS periodically and broadcasts requests to start or stop LRPs as needed, based on a comparison of desired and actual LRPs.
  
  The Diego Brain's [Auctioneer](./diego-pedia.html#auctioneer) distributes Tasks and LRPs to the cluster of Diego Cells via an [auction](./diego-auction.html) involving the Cell [Rep](./diego-pedia.html#rep)s.  
  
  See [The Diego Auction](./diego-auction.html) for more information about how tasks and LRPs are distributed in Diego.
  
  Once a Task or LRP is assigned to a Cell, the [Executor](./diego-pedia.html#executor) spins up a [Garden](./diego-pedia.html#garden) container and executes the specified work, which is encoded as a generic, platform-independent, recipe of composable [actions](https://github.com/cloudfoundry-incubator/receptor/blob/master/doc/actions.md).
  
  Diego interfaces with [Doppler](./diego-pedia.html#doppler) to provide real-time streaming logs for all Tasks/LRPs.  Diego also interfaces with [Gorouter](./diego-pedia.html#router) to automatically route web traffic to running LRP instances.
  
  Diego is packaged up as a bosh release called [**Diego-Release**](https://github.com/cloudfoundry-incubator/diego-release).
  
  
  ## <a id='diego-cf'></a> Diego and Cloud Foundry
  
  Diego is abstracted away from the Cloud Controller and other Cloud Foundry components such as the Loggregator and the Router. Non-Diego CF components consume Diego via the [Receptor API](https://github.com/cloudfoundry-incubator/receptor/blob/master/doc/README.md).
  
  Presently, there is a translation layer called the CC-Bridge that converts the [Cloud Controller](./diego-pedia.html#cloud-controller)'s domain-specific requests to stage and run applications into requests terms that Diego understands: Tasks and LRPs.  Eventually Cloud Controller will be modified to communicate directly with a Diego component called the [Receptor](./diego-pedia.html#receptor).
  
  The process of staging and running a CF application is complex and filled with platform and implementation-specific details.  We encapsulate these concerns in a triad of binaries known collectively as the [App Lifecycle](./diego-pedia.html#app-lifecycles).  The Tasks and LRPs produced by the CC-Bridge download the App Lifecycle binaries and run them to stage, start, and health-check CF applications.
  
  ## <a id='conclusion'></a>Working Together
  
  
negative.code: 
  These tests exercise a number of happy-path test cases across the entire stack.
  
  Use the CF CLI to run the tests.
  
  [**Diego-Acceptance-Tests on GitHub**](https://github.com/cloudfoundry-incubator/diego-acceptance-tests)
  
  