You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
local:exec which "just" starts a binary on the machine,
local:docker which relies on docker containers running on the machine,
cluster:k8s which relies on Kubernetes.
One of Testground promises (to be clarified) is to let a user run a test instance on a "mock network". You might use these feature to simulate custom topologies, network latency, etc (see https://docs.testground.ai/concepts-and-architecture/sidecar).
we might also want to run tests going through the "real" internet (benchmarks, ProbeLab, etc),
and we might want to compare testground results on a mocked network with testground results on real networks ("testing the testground").
One solution might be to add remote runners to testground which would let you (the user) run a test by ssh'ing on different machines you control and use the internet and real networks as the test.
Steps
Clarify what we need from remote:exec, remote:docker,
Define an architecture (are we using simple ssh, docker swarm, etc),
Currently, testground has 3 runners:
local:execwhich "just" starts a binary on the machine,local:dockerwhich relies on docker containers running on the machine,cluster:k8swhich relies on Kubernetes.One of Testground promises (to be clarified) is to let a user run a test instance on a "mock network". You might use these feature to simulate custom topologies, network latency, etc (see https://docs.testground.ai/concepts-and-architecture/sidecar).
But:
One solution might be to add
remoterunners to testground which would let you (the user) run a test by ssh'ing on different machines you control and use the internet and real networks as the test.Steps
remote:exec,remote:docker,