QA (public)

For now I will just need to wait until rsimai comes back to us with more specific information.

There was some movement and I was looking into which package versions are installed on our systems. I realized that we have one system still on Leap 15.4, osiris, upgrading now. Done. Inconsistencies come from #130648 when I removed the security:sensor repo to not be added anymore on more recent Leap 15.5 but we still kept the repo for newer versions.

Blocking on https://suse.slack.com/archives/C02NJAA1PEC/p1709382114636189?thread_ts=1709283079.201359&cid=C02NJAA1PEC

I realized that https://build.opensuse.org/project/repository_state/security:sensor/15.5 has only x86_64 enabled. Assuming that you would like us to test packages from that project can those architectures be enabled?

https://download.opensuse.org/repositories/security:/sensor/15.5/ now has all four main architectures enabled but seemingly no s390x builds. Anyway, will enable that for testing now.

Follow-up MRs merged because I messed up.

sudo salt \* cmd.run 'zypper -n in --allow-vendor-change velociraptor-client'

to force the update. All hosts within the LSG QE salt managed infrastructure except s390x and openqa-piworker now run velociraptor-client-0.7.0.4.git47.0f8a4de1-lp155.38.1 including the updated config pointing to https://10.156.231.185:8000/. I will monitor if there is any considerable performance impact on our infrastructure.

Evaluating our monitoring data from https://monitor.qa.suse.de/ on a sample size of 10 machines I could not find any significant impact on performance. So until further notice I would continue to run the development version on our hosts.

I was asked by email if we can help to test on ppc64le. For this I did ssh grenache-1.oqa.prg2.suse.org 'systemctl mask --now openqa-worker-auto-restart@7' which is for grenache-8 and on grenache (novalink) did pvmctl lpar power-on -i name=grenache-8

I answered Marcela Maslanova by email and stated that they can use grenache-8 for days/weeks and should let us know if we can return the machine back to the openQA testing pool. Added according rollback step.

As requested by email I now did

sudo salt -C 'G@osarch:s390x' cmd.run 'zypper ar -f -p 85 https://download.opensuse.org/repositories/security:/sensor/SLE_15_SP5/security:sensor.repo && zypper -n in velociraptor-client-0.7.0.4.git47.0f8a4de1-150500.38.2.s390x'

as https://download.opensuse.org/repositories/security:/sensor/15.5/ does not supply s390x although it would be preferred to use that repo instead and stay consistent.

The output in the system journal was a very verbose log dump ending with

Mar 26 21:36:08 s390zl12 velociraptor-client[83250]: libbpf: prog 'trace_vfs_ioctl': failed to load: -22
Mar 26 21:36:08 s390zl12 velociraptor-client[83250]: libbpf: failed to load object 'chattrsnoop

Complete journal of the old and new version:

http://w3.nue.suse.com/~okurz/velociraptor-client-log-s390zl12-2024-03-26T21:38:18+01:00.log

sent by email

I was asked about ARM testing ressources as well. For this I created an account "sensor-test" on openqaworker-arm-1 and I will add SSH keys when I get them for access.

rollback task done, checked successful start of openQA jobs on the formerly disabled grenache openQA worker instance, task resolved.