I've set fc27 to only run jobs requesting this label (as we still have lago_master_github_check-patch-fc27-x86_64 and jenkins_master_check-patch-fc27-x86_64 needing those) and am working on fc29 in

I took off all the fc27 slaves for now.

you're right, found it later, took the slave offline.

It was a fc27 slave after all:
09:32:36 [check-patch.el7.x86_64] Running on vm0162.workers-phx.ovirt.org in /home/jenkins/workspace/vdsm_standard-check-patch

Maybe we will disconnect them meanwhile?

this one failed on el7 slave, so maybe its not related to fc27?

Another failure:
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/243/

On Tue, Nov 27, 2018 at 1:38 PM Eyal Edri (oVirt JIRA) <

There are quite a few fc27 slaves - http://jenkins.ovirt.org/label/fc27/
Let's verify that indeed all of them are causing issues before removing them and causing lack of resources.

Nothing on those slaves desc indicated they have an issue, so I'm not sure that was the reason they were taken offline.
In any case if they are not OK, they should be reinstalled as centos 7.
can you reinstall all the fc27 slaves as centos7?
Probably best to bring them down now ( I would but I don't have access to jenkins for some reason, I can't login )

This looks like a very old known issue - this happens when someone sets up a slave when the jenkins UID/GID are 1000.

, - this seems to be all happenning on the fc27 slaves you brought up, I guess now we know why they were down in the 1st place...

WRT your 2nd issue - we actually have fixes for that where possible - but not in STDCI V1... The code structure of STDCI V1 makes this close to impossible to do there...

But for this particular issue, its not really possible to tell the difference because the failure is occurring in the innermost mock invocation that is launching your script...