QA » openQA Project » openQA Infrastructure

Sounds feasible but not related to openQA directly, at least not the upstream project, rather infrastructure definitions. Should be doable by everyone with access to salt pillars. @ph03nix any good reason why you couldn't just solve it yourself directly by adding a merge request to salt pillars?

okurz wrote:

Sounds feasible but not related to openQA directly, at least not the upstream project, rather infrastructure definitions. Should be doable by everyone with access to salt pillars. @ph03nix any good reason why you couldn't just solve it yourself directly by adding a merge request to salt pillars?

I unfortunately don't have any knowledge about our s390x workers, nor can I see where the physical machines are located.

You can now point me to people who I could ask how to do this. However I believe it's more economical that someone with knowledge takes this task, instead of me bugging them on how to do it.

I wanted to offer you a way for self-service to solve your own problems but maybe I couldn't make that clear. So I will pick up this ticket and try to help more.

I asked in chat who would like to support: https://suse.slack.com/archives/C02CANHLANP/p1650618602282939
and gladly szarate quickly reacted.

With a combination of

for i in $(sed -n 's/VIRSH_HOSTNAME: \(s390.*\)/\1/p' openqa/workerconf.sls  | sort | uniq); do echo $i; sshpass -p XXX ssh-copy-id root@$i; done

to setup the initial connection to each s390 qemu machine we have defined within salt pillars I did

for i in $(sed -n 's/VIRSH_HOSTNAME: \(s390.*\)/\1/p' openqa/workerconf.sls  | sort | uniq); do echo $i; ssh root@$i "grep sie /proc/cpuinfo" ; echo $?; done

so seems like all machines already have "sie".

I checked all s390 machines we have for qemu in salt pillars and can confirm that sie is there on s390zp{12,14,15,17,18,19}. Maybe define to pass all flags from the host machine in libvirt?

EDIT: I guess maybe something in https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/installation/bootloader_zkvm.pm ?

I'm closing this issue, as the root cause for the request of a new worker class originated from a wrong configuration (https://progress.opensuse.org/issues/110155#note-12) and it got resolved in the meantime.

No need for an additional WORKER_CLASS, the systems are not behaving as expected.