Schedule test modules to debug poo#88273 #12791
Conversation
This commit adds the info/show_hdd_info test module. The purpose of the module is to record in the test details and in autoinst-log information such as name, size and checksum digest for HDD_# test assets.
This commit adds the console/check_boot_files test module, the purpose of which is to record in the test details MD5 checksums for files in /boot. It will focus exclusively on vmlinu*, initrd*, config*, sysctl* and symver*.
alvarocarvajald
force-pushed
the
poo#88273
branch
from
6784cd8
to
c7428eb
Compare
There was a problem hiding this comment.
In your git commit message subject s/uptate/update/
But in general, do you actually need this changed merged to master or just want to have it temporarily and use http://open.qa/docs/#_triggering_tests_based_on_an_any_remote_git_refspec_or_open_github_pull_request
alvarocarvajald
force-pushed
the
poo#88273
branch
from
c7428eb
to
fcf0cd6
Compare
Fixed.
You have a point that this may not be required to be merged to master, as outside of this poo investigation, I don't see how useful the new modules would be and they are not actually testing anything. I've added the WIP label so this is not accidentally merged while I go the Two things though:
|
|
Testing with CASEDIR it's only set in the support server, so this will not do anything :( |
Any test coverage for multi-machine features is still far inferior to single-machine operations so there might still be problems. At least openqa-clone-job can handle multi-machine jobs and openqa-clone-custom-git-refspec is using that so it might work, can't promise though. As alternative you can also post jobs or isos with the parameter CASEDIR pointing to a git repo. My idea behind |
|
Tried with: But CASEDIR it's only on the parent job as well:
I expected command line settings from |
Add |
That did the trick. Thanks! |
|
We have some results there, so I don't think there's any need to merge this into master anymore. Closing the PR. |
The ticket https://progress.opensuse.org/issues/88273 describes a frequent test failure on the QAM TestRepo 12-SP3 HA rolling update tests that requires more investigation.
This PR is adding 2 modules to check some assets' integrity both in the worker and in SUT to verify if changes to these files could explain the frequent issues.
The issue itself can be described as follows: 2 MM jobs are started from the same qcow2 image in the same job group, to eventually configure them as an HA cluster; before any HA configuration is done, both SUT boot from the qcow2, are registered to SCC with
migration/register_systemand updated withupdate/zypper_up; then both SUT are rebooted. and even though by this time both tests should be identical, one of them is seen successfully booting, while the other shows anInvalid Magic Numbererror in grub while booting and fails the test, failing the whole MM job: https://openqa.suse.de/tests/6323075#step/console_reboot/4Issue is frequent enough in openqa.suse.de to be a concern (https://openqa.suse.de/tests/6323075#next_previous), but cloning the job into our development environment shows the test always passing: http://mango.qa.suse.de/tests/4140#next_previous
Tests were moved from openqaworker10 to openqaworker9 as an initial attempt to fix/gather more details on the failure, but this has not changed the outcome in openqa.suse.de, which is why these changes are now being submitted.