There are use cases for running two instances of the same test in parallel, allowing network communication between the tests.
This comes mainly from the RHTS / Beaker sphere where such functionality is/was common, and it also got added to tmt, so the main target is running fmf tests.
So the idea would be to
- split-off non-multihost tests and run them via regular AdHocOrchestrator
- run multihost tests on the side via a second Orchestrator
The MultihostOrchestrator would probably reserve two systems from the same Provisioner (helping with network connectivity) and treat the pair of systems as a combined unit (perhaps via a namedtuple), to be reserved/released both at the same time.
It doesn't need sophisticated ad-hoc scheduling, just linear execution is fine. Even treating all tests as destructive (not reusing reserved systems) might be fine - the typical pattern is "a handful" of multihost tests, perhaps less than 10.
The new MultihostOrchestrator would, however, need to support non-blocking serve_once() to work alongside other Orchestrators in the same Python process.
There are use cases for running two instances of the same test in parallel, allowing network communication between the tests.
This comes mainly from the RHTS / Beaker sphere where such functionality is/was common, and it also got added to tmt, so the main target is running fmf tests.
So the idea would be to
The MultihostOrchestrator would probably reserve two systems from the same Provisioner (helping with network connectivity) and treat the pair of systems as a combined unit (perhaps via a
namedtuple), to be reserved/released both at the same time.It doesn't need sophisticated ad-hoc scheduling, just linear execution is fine. Even treating all tests as destructive (not reusing reserved systems) might be fine - the typical pattern is "a handful" of multihost tests, perhaps less than 10.
The new MultihostOrchestrator would, however, need to support non-blocking
serve_once()to work alongside other Orchestrators in the same Python process.