QA » openQA Project » openQA Tests » qe-yam

set MAX_JOB_TIME=7200 for offline_sles15sp1_sles15sp4_sles15sp5_media_all_full_s390x_ph0 7200

and for
https://openqa.suse.de/t107305401
https://openqa.suse.de/t107305401
https://openqa.suse.de/t107305402

now,we can just focus on the ARM and s390x-kvm-sle12 cases by now.

links are not available, could you please paste the MR?

• for Aarch64 flavor Continuous-Migration-SLE15SP5 we've set MAX_JOB_TIME=14400, and no case failed for timeout since then.
• in 88.1 no cases failed for execution time > MAX_JOB_TIME.

• MR 283

VR: https://openqa.suse.de/tests/10902596

• for the latest 90.1 build, there are some s390x failed with svirt_upload_assets.
• the reason is that the qcow files are more than 13~15GB and the worker was slow. after rerun both passed in 2 hours.
• tests in 90.1 after rerun
  • https://openqa.suse.de/tests/10912233
  • https://openqa.suse.de/tests/10912235

Now in build 93.2 AKA PublicRC-202304, all cases{include s390x} are finished for the MAX_JOB_TIME.

OK. I'd take a look for the detail.

hjluo wrote:

OK. I'd take a look for the detail.

Last one passed, but can you run it 5-10 times to see if the timeout is enough?

• now the failed one is online_sles15sp3_sles15sp4_sles15sp5_scc_all_full_yast_s390x_ph0_1 and I've run 20_instances with MAX_JOB_TIME=14400 to check it.

• The one that for this ticket offline_sles15sp1_sles15sp4_sles15sp5_media_all_full_s390x_ph0 was blocked by a bug1210196

from the result_page, 5 out of 20 cases passed, the rest were failed at svirt_upload_assets, but not for timeout, some case just run less than 14400 seconds.

run with a branch to extend the timeout.

for i in {1..5}; do
bash -x  ./hj-tools/hj-branch.sh -a  hjluo -b  svirt_upload -j 11153512 -s "_GROUP=0 MAX_JOB_TIME=14400  TEST=online_sles15sp3_sles15sp4_sles15sp5_scc_all_full_yast_s390x_ph0_${i} _SKIP_POST_FAIL_HOOKS= PUBLISH_HDD_1=SLES-15-SP5-s390x-Build101.1-15SP3-15SP4-ph0_${i}.qcow2 PUBLISH_PFLASH_VARS=SLES-15-SP5-s390x-Build101.1-15SP3-15SP4-ph0-uefi-vars-${i}.qcow2"

The running_jobs

now the VR was blocked by the ERRICSSON repo issue, the PR owner is now fixing it. https://suse.slack.com/archives/C02D16TCP99/p1685687709108189, it now blocked all zypper_patch.

now using [writeback option to fast the qemu-imge convert speed.

'writeback' uses the page cache, considering the write complete when the data is in the page cache, and reading data from the page cache. This is likely to give the best performance but is also likely to give inconsistent performance and cause trouble for other applications.

reference:

• 1 qemu: Make disk image conversion dramatically faster
• 2 how to improve qcow performance?

PR: 17222

PR was merged.