https://github.com/onsi/auction
https://github.com/onsi/auction
Last synced: 6 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/onsi/auction
- Owner: onsi
- Created: 2014-05-08T17:08:03.000Z (about 12 years ago)
- Default Branch: master
- Last Pushed: 2014-05-19T15:48:02.000Z (about 12 years ago)
- Last Synced: 2024-12-29T09:28:49.738Z (over 1 year ago)
- Language: Go
- Size: 3.29 MB
- Stars: 0
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Auction
Auction implements the scheduling algorithm for Diego's long running processes. It does this by codifying two players in the scheduling game:
## The Auctioneer
The `auctioneer` package provides a variety of auction algorithms. Diego nodes that play the `auctioneer` role must call `auctioneer.Auction` passing in a valid `types.AuctionRequest` and `types.RepPoolClient` for communciating with the pool of auction representatives.
## The Representatives
The `auctionrep` package provides an implementation of `AuctionRep`. These `AuctionRep`s follow the rules of the auction correctly but need to be provided with an `AuctionRepDelegate` that performs the actual work of tracking resources, reserving instances, and starting them running.
## Communication
The auctioneers must be able to communicate with the auctionreps via some protocol. The communication package provides implementations for `servers` (to be run on the representative nodes) and `clients` to be constructed and used on the `auctioneer` node.
Currently `Auction` provides two remote communication packages: `nats` and `rabbit`.
## Simulation
Because communication has been separated from implementation, and because the implementation of the auctioneer and auctionrep has been built to be reusable, it is possible to construct a comprehensive simulation to test the various scheduling algorithms, using various communication schemes, on various infrastructures.
This is done in the simulation package which is the defacto "test suite" that ensures the auction is played correctly. As new scheduling features are added, a corresponding simulation should be added to the simulation suite.
In addition to `nats` and `rabbit`, the simulation suite provides an *inprocess* means of communication. This allows a feel of representatives and auctioneers to be started as goroutines in-process and allows for rapid iteration on the underlying scheduling algorithm.