action #19122
closed[tools]Setup of shared ppc64le worker for development
0%
Description
Setup story¶
Since we often need a architecture or machine specific change to the test code or change in test code that is likely to behave different depending on the architecture it makes sense to have development instances for non-hammer architecture available as well besides the production instances. I am trying to setup a ppc64le worker on shiraz-2, a virtual machine running on shiraz.arch.suse.de.
Steps I did so far to progress:
- Install SLES 12 SP2
- Install qemu-system-ppc64le from standard SLES repo
- Install openQA from devel:openQA *
zypper ar -r http://download.opensuse.org/repositories/Virtualization/SLE_12/Virtualization.repo
modprobe kvm kvm_pr
zypper in qemu-vgabios qemu-ipxe
rsync -aHP shiraz-3:/usr/share/qemu/slof.bin /usr/share/qemu/slof.bin
/usr/share/qemu/slof.bin has md5sum dee802a9f7d906c49150c6e6f61240a0
that failed now in http://lord.arch/tests/6203#step/boot_to_desktop_sym/7 with "Facility 'TM' unavailable, exception" and kernel panic.
Trying with qemu from Virtualization repo which also overwrote /usr/share/qemu/slof.bin (md5sum 5cc28a978f5b6ff657c9ed2779ceb3e3). Seems to work better now http://lord.arch/tests/6204#live
Worker configuration¶
- login as user to shiraz-2
Use sudo (without password) to configure the openQA worker configuration files
- add your host in workers.ini
- add credentials in client.conf
Make sure your webUI host delivers tests+assets over e.g. rsync server (without authentication read-only)
Restart worker
Ready to accept jobs
Example setup:
vim /etc/openqa/workers.ini /etc/openqa/client.conf
Test rsync with
/etc/rsync.conf example
gid = nobody
uid = nobody
read only = true
use chroot = true
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
slp refresh = 300
use slp = false
[tests]
path = /var/lib/openqa/share/tests
comment = OpenQA Test Distributions
rsync rsync:///tests
it should list tests directory content without asking for authentication.
Then restart workers 1 and 2, make sure they don't show errors and clone a job.
Updated by okurz almost 7 years ago
seems to work quite nicely, e.g. see http://lord.arch/tests/6207#live
Now the instructions can be added to a wiki
Updated by okurz almost 7 years ago
after an upgrade of packages slof is busted: http://lord.arch/tests/6294#live stupid me, making an update…
Updated by okurz almost 7 years ago
- Status changed from In Progress to Feedback
- Priority changed from Normal to High
help would be appreciated
Updated by okurz almost 7 years ago
- Blocks coordination #18964: [functional][epic][u]Bootloader/boot functions refactor added
Updated by okurz almost 7 years ago
- Priority changed from High to Normal
nsinger tried to help me, I tried out different versions of slof image but still we always end up in the slof menue listing some weird pci device that slof fails to boot from: http://lord.arch/tests/6329#step/bootloader/10
$ ssh root@shiraz-2.arch "ls -l /usr/share/qemu/slof*"
lrwxrwxrwx 1 root root 48 May 29 12:43 /usr/share/qemu/slof.bin -> slof.bin.malbec.86f680577aa3dedcb113550b1594c0e1
-rw-r--r-- 1 17254 50 903192 May 29 12:39 /usr/share/qemu/slof.bin.malbec.86f680577aa3dedcb113550b1594c0e1
-rw-r--r-- 1 root root 906248 May 5 15:27 /usr/share/qemu/slof.bin.orig.5cc28a978f5b6ff657c9ed2779ceb3e3
-rw-r--r-- 1 root root 906248 Apr 20 19:20 /usr/share/qemu/slof.bin.shiraz-3_variant.dee802a9f7d906c49150c6e6f61240a0
all of them don't seem to make a difference now but when I originally set up not all managed to boot into an installed hdd or into the DVD installer.
Anyway, prio can be reduced now after nsinger registered ps64vt1069:1 to lord.arch, thx.
Updated by okurz over 6 years ago
For whatever reason shiraz-2 seems to be up and happy so far again: http://lord.arch/tests/7123
Updated by okurz over 6 years ago
nsinger created a wiki page for documentation of shared workers: https://wiki.microfocus.net/index.php/SUSE-Quality_Assurance/Labs/Shared_workers
Updated by okurz over 6 years ago
- Subject changed from Setup of shared ppc64le worker for development to [tools]Setup of shared ppc64le worker for development
Updated by okurz about 6 years ago
- Status changed from Feedback to Resolved
For now it's working good enough for us. I think the original issue can still be improved but we mainly have a way how to get corresponding workers when needed so closing.