I managed to mess up the settings of quite some jobs on osd overwriting the worker class with "s390x-kvm-sle15". Trying to repair that. With something like select test,arch,machine,value from jobs,job_settings where jobs.id = job_settings.job_id and state='scheduled' and key='WORKER_CLASS' and value='s390x-kvm-sle15' limit 10; I can look up the incorrectly configured jobs. Turns out with select count(test) from jobs,job_settings where jobs.id = job_settings.job_id and state='scheduled' and key='WORKER_CLASS' and value='s390x-kvm-sle15'; that it's 1090 jobs, not too bad ;) I should be able to lookup the correct worker class settings from each machine setting. With select name,value from machines,machine_settings where machines.id = machine_settings.machine_id and key='WORKER_CLASS'; we can show all worker class per machine. With select value from machines,machine_settings where machines.id = machine_settings.machine_id and key='WORKER_CLASS' and name=(select machine from jobs where id=$id); we can get the worker class that a job $id should have.
So we should be able to update the worker class from the machine
for job in $(sudo -u geekotest psql --tuples-only --command="select job_id from job_settings where state='scheduled' and key='WORKER_CLASS' and value='s390x-kvm-sle15';" openqa); do sudo -u geekotest psql --command="update job_settings set value=(select value from machines,machine_settings where machines.id = machine_settings.machine_id and key='WORKER_CLASS' and name=(select machine from jobs where id=$job)) where job_id=$job and key='WORKER_CLASS';" openqa; done
Let's see what that breaks now :D
EDIT: oorlov informed me that I am only fixing "scheduled" jobs. Of course. So I also applied the above without the state='scheduled' filter. That's running for long.
EDIT: I optimized a bit by running the complete command as "geekotest" so skipping the sudo's