Suboptimal advance booking of Jenkins slaves for testing ISOs

Today we’ve seen a case when an isotesterN was idle, while a test_Tails_ISO_isotesterN job was waiting in queue. Ideally, this should not happen.

If I understood bertagaz’ analysis right: a given run of a given test_Tails_ISO_isotesterN job can be put in queue because another job of that kind is running already. In such a case, the new run has been scheduled to run on a specific slave (that was just rebooted) already. And then, when the old run is completed and no concurrency issue prevents the new run from starting, the slave it was scheduled to run on can very well be busy with another job run.

In practice, even if this suboptimal scheduling is not fixed, there are great chances that we run enough test suite to avoid seeing idle isotesterN slaves, so we should not be wasting resources. We’ll just be running jobs in a suboptimal order. If we are inclined to decide it’s no big deal, we should first evaluate by how many hours this can delay a given test suite run in the worst case.

Parent Task: #9486 (closed)

Related issues

• Related to #11295

Original created by @intrigeri on 10215 (Redmine)