Allow limiting the number of concurrent TestRuns (maybe even per "target" or "SUT")

[frittentheke]

Feature Description

Currently the operator works on all TestRun resources and moves them through the state machine

• initialization
• initialized
• created
• started
• stopped
• finished
• error

It might make sense to allow restricting the number of concurrent TestRuns to avoid interference of individual runs. This might be due to noisy neighbors issue on the K8 cluster / infrastructure running the K6 pods but more importantly in cases where the same system under test (SUT) is targeted by multiple TestRuns.

Suggested Solution (optional)

1. Introduce a setting to limit the number of concurrently executed TestRuns.

• Extend the TestRunStatus with pending or queued to indicate back to the user that the TestRun is waiting for others to finish.
• Ensure first-come-first-served by sorting by TestRun creation date!
• Maybe it makes sense to already run the initializer pod to report back issues with the tests without making the user wait for the actual run.

2. The use-case I have in mind is about limiting the number of concurrent tests hitting the same system under test / target. So to extend on the limitation of concurrent TestRuns it would also be beneficial to allow to set a limit per "SUT". Either by extending the TestRun CR with a field to indicate which target will be hit or by an annotation. Yes, the real world is always more complex, so there might be even more rules that some environments would like followed.

But by allowing the k6-operator to work through a list (~ queue) of TestRuns one by one per SUT seems to cover the 90%-use-case of avoiding interference of tests (towards the same target)

Already existing or connected issues / PRs (optional)

No response