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: sysadmin#9486 (closed)
- Related to sysadmin#11295 (closed)