28110d34be
I'm going to try splitting the tap jobs across multiple worker hosts. We have quite a lot of tap jobs, now, and I have seen sometimes a situation where all non-tap jobs have been run and the non-tap worker hosts are sitting idle, but the single tap worker host has a long queue of tap jobs to get through. We can't just put multiple hosts per instance into the tap class, because then we might get a case where job A from a tap group is run on one host and job B from a tap group is run on a different host, and they can't communicate. It's actually possible to set this up so it works, but it needs yet more complex networking stuff I don't want to mess with. So instead I'm just gonna split the tap job groups across two classes, 'tap' and 'tap2'. That way we can have one 'tap' worker host and one 'tap2' worker host per instance and arch, and they will each get about half the tap jobs. Unfortunately since we only have one aarch64 worker for lab it will still have to run all the jobs, but for all other cases we do have at least two workers, so we can split the load. Signed-off-by: Adam Williamson <awilliam@redhat.com>
1 line
16 B
Text
1 line
16 B
Text
openqa_tap: tap
|