This design document describes the motivation for adding Remote Runners to Testground, the description of what the feature should look like, how to implement it, open questions, and discuss a few pros & cons,
| Authors | |
|---|---|
| Status | Ready for review |
| Published | 2022-08-09 |
| Approved | Pending… |
| Epic |
Reviewers:
| Ack / Nack | ||
|---|---|---|
| Marten | go-libp2p maintainer - requested the feature | |
| Bloxico | Testground maintainers | |
| Piotr | Testground maintainer | |
| Anton | Testground legacy maintainer | |
| Marco | non-blocking, just want to stay in the loop. (libp2p maintainer) |
The libp2p team wants to assess libp2p performances against other competing technologies such as HTTP. https://github.com/libp2p/test-plans/issues/27
The way we could solve their problem is with a set of benchmarking scripts that connect to a few machines around the internet. These scripts would take benchmark code, build it, deploy binaries, run them, eventually synchronize instances, then gather results. That looks like reinventing Testground.
One of Testground’s promises is to simulate a credible network. It would be nice to be able to compare Testground runs on a simulated network vs Testground runs on a real network.
Finally, there might be more use cases for these runners, among others:
Currently, Testground provides 3 runners. A runner is an abstraction we use to schedule test instances “somewhere”:
local:exec starts a binary on the machine,