Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
This branch is 3 commits ahead, 48 commits behind onsi:master.

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


  • Auctioneer
  • Representative
  • Instance
  • In-process algorithm simulation
  • Textual visualization
  • Naive HTTP (too many open files)
  • Naive NATS topology (pub/sub per rep per vote)
  • Collated NATS topology (one pub/sub per vote across all reps)
  • Pull out common client interface
  • [] Organize by communication medium
  • [] One rep binary for all communication
  • [] All client methods should return an error
  • [] Refactor tests
  • [] Separate Auctioneer (server) from AuctionDistributer (client)
  • [] Move suites into communication medium and extract formatting into a visualization package
  • [] Text visualization can be written without reference to reps?
  • [] Implement connection limiting (semaphore) in http client and server
  • [] RPC ?
  • [] Bosh deploy representatives that support all three protocols
  • [] Run trials on AWS
  • [] Improved visualizations (animations?)
  • [] Test suite that runs different scenarios and actually fails if the distribution is invalid.
  • [] Identify entry points for using the Auctioneer package and Representative package in actual components.
    • Ideally the algorithm is safely locked up and tested in the Auction repo.
    • Consumers simply provide methods that the Auction repo guarantees are called correctly (order really matters here!)


  • Optimizations
    • Limit Rep bidding pool (value of choice: 20)
    • Limit max number of concurrenct auctions (value of choice: 20)
    • [] Repick bidding pool between rounds
    • [] Limit second-round vote to top-3 (?) bidders
  • Scoring functions
    • Memory
    • App Distribution
    • [] Memory & Disk
  • Scenarios [X] Empty reps => large swarm of starts of 1-instance apps [X] Non-empty reps (poor distribution) => large swarm of starts of 1-instance apps [X] Empty reps => N multi-instance apps [X] Seed reps with N multi-instance apps, then deploy M more [X] Seed subset of reps with N multi-instance apps, then deploy M more across all reps [] Many very full reps and few empty ones - how does this play with MaxConcurrent. Is it improved by repicking between rounds?


No description, website, or topics provided.






No releases published


No packages published


  • Go 100.0%