openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-01-25T15:19:39ZopenSUSE Project Management Tool
Redmine openQA Project - action #123664 (New): os-autoinst does not flush serial console buffer on snapsh...https://progress.opensuse.org/issues/1236642023-01-25T15:19:39ZMDouchamartin.doucha@suse.com
<p>When tests fail with kernel backtraces, the stale backtrace will be reported again after snapshot reload and trigger bogus failure even when the next test is successful.<br>
Example: <a href="https://openqa.suse.de/tests/10371180#step/cve-2017-1000111/13" class="external">https://openqa.suse.de/tests/10371180#step/cve-2017-1000111/13</a><br>
dmesg log: <a href="https://openqa.suse.de/tests/10371180/logfile?filename=serial0.txt" class="external">https://openqa.suse.de/tests/10371180/logfile?filename=serial0.txt</a></p>
<p>Here, the LTP test <code>cve-2017-18075</code> triggered kernel warning and failed. But the same kernel warning gets reported again at the end of test <code>cve-2017-1000111</code> which was successful and the dmesg log does not show any additional backtraces from it.</p>
<p>This appears to be os-autoinst regression because IIRC kernel backtrace detection used to work fine and only reported errors once.</p>
openQA Project - action #121774 (In Progress): LTP cgroup test appears to crash OpenQA worker ins...https://progress.opensuse.org/issues/1217742022-12-09T13:36:47ZMDouchamartin.doucha@suse.com
<p>LTP test cgroup_fj_stress_blkio_4_4_each on latest SLE-15SP1 KOTD kernel appears to crash the OpenQA worker instance it's running on. The test itself will succeed but the OpenQA job will stay stuck in <code>wait_serial()</code> for several hours (despite 90 second timeout) until the whole job fails on MAX_JOB_TIME. There are 3 examples so far:<br>
<a href="https://openqa.suse.de/tests/10089424#step/cgroup_fj_stress_blkio_4_4_each/7" class="external">https://openqa.suse.de/tests/10089424#step/cgroup_fj_stress_blkio_4_4_each/7</a><br>
<a href="https://openqa.suse.de/tests/10111009#step/cgroup_fj_stress_blkio_4_4_each/7" class="external">https://openqa.suse.de/tests/10111009#step/cgroup_fj_stress_blkio_4_4_each/7</a><br>
<a href="https://openqa.suse.de/tests/10113099#step/cgroup_fj_stress_blkio_4_4_each/7" class="external">https://openqa.suse.de/tests/10113099#step/cgroup_fj_stress_blkio_4_4_each/7</a></p>
<p>I've seen this issue only on SLE-15SP1 KOTD builds 156 and 157. I have not seen any cases on other SLE versions.</p>
<p>Typical autoinst-log.txt entries related to the timeout:</p>
<pre><code>[2022-12-06T08:52:27.432374+01:00] [debug] <<< testapi::script_run(cmd="vmstat -w", output="", quiet=undef, timeout=30, die_on_timeout=1)
[2022-12-06T08:52:27.432549+01:00] [debug] tests/kernel/run_ltp.pm:334 called testapi::script_run
[2022-12-06T08:52:27.432710+01:00] [debug] <<< testapi::wait_serial(record_output=undef, regexp="# ", quiet=undef, no_regex=1, buffer_size=undef, expect_not_found=0, timeout=90)
[2022-12-06T10:39:58.278597+01:00] [debug] autotest received signal TERM, saving results of current test before exiting
[2022-12-06T10:39:58.278622+01:00] [debug] isotovideo received signal TERM
[2022-12-06T10:39:58.278748+01:00] [debug] backend got TERM
</code></pre>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/10091628" class="external">4.12.14-150100.156.1.gb6c27ee</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Server-DVD-Incidents-Kernel-KOTD&machine=64bit&test=ltp_controllers&version=15-SP1" class="external">latest</a></p>
<a name="Steps-to-reproduce"></a>
<h2 >Steps to reproduce:<a href="#Steps-to-reproduce" class="wiki-anchor">¶</a></h2>
<ol>
<li>Run <code>ltp_controllers</code> testsuite on SLE-15SP1 KOTD</li>
<li>Wait.</li>
</ol>
openQA Infrastructure - action #115925 (New): aarch64: Random QEMU failures while retrieving host...https://progress.opensuse.org/issues/1159252022-08-29T08:44:02ZMDouchamartin.doucha@suse.com
<p>Since the worker upgrade to Leap 15.4, some aarch64 jobs have randomly failed with the following error: <code>qemu-system-aarch64: Failed to retrieve host CPU features</code><br>
Example: <a href="https://openqa.suse.de/tests/9401654" class="external">https://openqa.suse.de/tests/9401654</a></p>
openQA Project - action #114643 (New): Add support for virtio keyboard and mouse on aarch64 QEMUhttps://progress.opensuse.org/issues/1146432022-07-25T12:33:10ZMDouchamartin.doucha@suse.com
<p>QEMU aarch64 VMs are currently hardcoded to use USB keyboard in OpenQA. We now need to test SLE-15SP4 kernel-azure where this does not work because the whole USB subsystem is intentionally disabled and therefore the framebuffer console gets no keyboard input:<br>
<a href="https://openqa.suse.de/tests/9122772#step/update_kernel/95" class="external">https://openqa.suse.de/tests/9122772#step/update_kernel/95</a></p>
<p>I can get the tests to work by setting <code>QEMU_APPEND=device virtio-keyboard -device virtio-mouse</code>. Please implement proper support for virtio input devices in the QEMU backend.</p>
openQA Project - action #112337 (Workable): [ui/ux][easy] OpenQA admin UI: Link to last match of ...https://progress.opensuse.org/issues/1123372022-06-13T13:03:14ZMDouchamartin.doucha@suse.com
<p>[ui/ux][easy] OpenQA admin UI: Link to last match of a needle points to invalid URL size:M</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Some "Last Match" links in <a href="https://openqa.suse.de/admin/needles" class="external">https://openqa.suse.de/admin/needles</a> (if the needle had a recent match) point to invalid URL: <a href="https://openqa.suse.de/admin/undefined" class="external">https://openqa.suse.de/admin/undefined</a></p>
<a name="Steps-to-reproduce"></a>
<h2 >Steps to reproduce<a href="#Steps-to-reproduce" class="wiki-anchor">¶</a></h2>
<p>For example of the issue, on <a href="https://openqa.suse.de/admin/needles" class="external">https://openqa.suse.de/admin/needles</a> enter <code>license-insert-disc</code> into the search input box.</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>entrance level issue</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> Link is fixed</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Extend tests to ensure we have that covered</li>
</ul>
openQA Project - action #109929 (New): Snapshot rollback after SUT reboot breaks console switchinghttps://progress.opensuse.org/issues/1099292022-04-13T16:08:03ZMDouchamartin.doucha@suse.com
<p>If the SUT gets rebooted between snapshot creation and rollback, console state will not be properly restored and <code>select_console()</code> will fail in some cases because it'll try to log in when the user is already logged in since before the snapshot:<br>
<a href="https://openqa.suse.de/tests/8545133#step/select_console#1/2" class="external">https://openqa.suse.de/tests/8545133#step/select_console#1/2</a></p>
<p>Steps to reproduce:</p>
<ol>
<li>Activate 2 or more consoles</li>
<li>Create snapshot</li>
<li>Reboot SUT and call <code>wait_boot()</code> (<code>reset_consoles()</code> will be called by <code>wait_boot()</code> here)</li>
<li>Activate the same consoles again (all of them will be added to <code>$autotest::last_milestone->{activated_consoles}</code> due to <code>reset_consoles()</code> above)</li>
<li>Trigger snapshot rollback</li>
<li>Select any console activated in step 1 except the one that was selected during snapshot creation</li>
</ol>
<p>If the console selected in the last step expects login prompt on first activation and then keeps the session open even while not selected, it'll fail to activate after snapshot rollback. The console session was left open in the snapshot but the test backend will wrongly believe that it's closed due to steps 3 and 4 causing another console reset during snapshot rollback.</p>
openQA Infrastructure - action #108266 (New): grenache: script_run() commands randomly time out s...https://progress.opensuse.org/issues/1082662022-03-14T09:36:30ZMDouchamartin.doucha@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Since the NBG server room was moved, I'm seeing a lot of random script_run() command timeouts on grenache. I suspect network issues.<br>
<a href="https://openqa.suse.de/tests/8320677#step/sighold02/12">https://openqa.suse.de/tests/8320677#step/sighold02/12</a><br>
<a href="https://openqa.suse.de/tests/8294410#step/fallocate06/8">https://openqa.suse.de/tests/8294410#step/fallocate06/8</a><br>
<a href="https://openqa.suse.de/tests/8294334#step/boot_ltp/42">https://openqa.suse.de/tests/8294334#step/boot_ltp/42</a></p>
<pre><code> Test died: command 'vmstat -w' timed out at /usr/lib/os-autoinst/testapi.pm line 1039.
# Test died: Timed out waiting for LTP test case which may still be running or the OS may have crashed! at sle/tests/kernel/run_ltp.pm line 337.
# Test died: command 'rpm -qi kernel-default > /tmp/kernel-pkg.txt 2>&1' timed out at /usr/lib/os-autoinst/testapi.pm line 1039.
main::init_backend() called at /usr/bin/isotovideo line 258
[2022-03-09T16:12:24.052826+01:00] [info] ::: consoles::serial_screen::read_until: Matched output from SUT in 1 loops & 0.00229895696975291 seconds: Use of uninitialized value $regexp in concatenation (.) or string at /usr/lib/os-autoinst/testapi.pm line 927.
testapi::wait_serial(undef, undef, 0, "no_regex", 1) called at sle/tests/kernel/run_ltp.pm line 317
run_ltp::run(run_ltp=HASH(0x1001999aee8), LTP::TestInfo=HASH(0x1001b24d630)) called at /usr/lib/os-autoinst/basetest.pm line 356
cf. last good
[2022-03-12T07:06:13.797172+01:00] [info] ::: consoles::serial_screen::read_until: Matched output from SUT in 1 loops & 0.00224426796194166 seconds:
Use of uninitialized value $regexp in concatenation (.) or string at /usr/lib/os-autoinst/testapi.pm line 927.
testapi::wait_serial(undef, undef, 0, "no_regex", 1) called at sle/tests/kernel/run_ltp.pm line 317
run_ltp::run(run_ltp=HASH(0x1003570fb08), LTP::TestInfo=HASH(0x1003547afa8)) called at /usr/lib/os-autoinst/basetest.pm line 356
eval {...} called at /usr/lib/os-autoinst/basetest.pm line 354
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> Users no longer file complaints about script_run timing out</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Find a reproducer or database query to identify recent cases e.g. ask Martin. EDIT: mdoucha responded that there is no special query available. Next suggestion: Just pick any recent job where the problem happened, trigger 1k jobs for investigation, e.g. according priority or over weekend, etc.</li>
<li>Look into warnings in logs</li>
<li>"Use of uninitialized value $regexp in concatenation (.) or string" is already fixed</li>
<li>last good: <a href="https://openqa.suse.de/tests/8315985">https://openqa.suse.de/tests/8315985</a></li>
<li>[debug] Current version is 4.6.1647014989.7540333c [interface v25]
<ul>
<li>Do <code>git log --no-merges 7540333c..$first_bad</code></li>
</ul></li>
<li><p>Investigate the timeout handling c.f. recent improvements to VNC connection code and handling former blocking code paths</p>
<ul>
<li>We don't have a screenshot to compare the serial output to</li>
<li>Maybe we can check the serial logs for comparison?</li>
</ul></li>
</ul>
<p>All these occurences are on the same machine, which is s390x-kvm-sle12</p>
<p>One problem I see is that in <a href="https://openqa.suse.de/tests/8505116#step/shutdown_ltp/6">https://openqa.suse.de/tests/8505116#step/shutdown_ltp/6</a> we have a serial terminal. If there would be VNC we would be able to see if the command was executed or not. I also don't see the commands in <a href="https://openqa.suse.de/tests/8505116/logfile?filename=serial_terminal.txt">https://openqa.suse.de/tests/8505116/logfile?filename=serial_terminal.txt</a> nor serial0.txt .</p>
<p>We should try to resolve the ambiguity if commands just never write to the serial terminal as they time out or if actual data is going missing from SUT to worker.</p>
<p>What would you say, what is the best way to reproduce the issue? If we have a reproducer we can try to make it as small as possible and then fix it, maybe just increase the timeout. Maybe ensure that we cath any console related processes in the background if they are still responsive.</p>
<a name="Further-suggestions-from-SUSE-QE-Tools-unblock-2022-05-11"></a>
<h3 >Further suggestions from SUSE QE Tools unblock 2022-05-11<a href="#Further-suggestions-from-SUSE-QE-Tools-unblock-2022-05-11" class="wiki-anchor">¶</a></h3>
<ul>
<li>As suggested in <a class="issue tracker-4 status-1 priority-4 priority-default child" title="action: grenache: script_run() commands randomly time out since server room move (New)" href="https://progress.opensuse.org/issues/108266#note-22">#108266#note-22</a>, similar as we do for openQA worker hosts there should be monitoring to critical components (out of scope for SUSE QE Tools, delegate to SUSE QE Core)</li>
<li>within the code called by script_run using ssh
<ul>
<li>retry</li>
<li>check if the ssh connection is still there at all</li>
<li>provide more details when failing</li>
</ul></li>
<li>Add in the message on timeout how long we waited</li>
</ul>
openQA Project - action #96507 (New): Job terminated prematurely during needle check auto_review:...https://progress.opensuse.org/issues/965072021-08-03T11:18:44ZMDouchamartin.doucha@suse.com
<p>Two LTP jobs have failed recently in a similar way while waiting for needle match.</p>
<p><a href="https://openqa.suse.de/tests/6638157" class="external">https://openqa.suse.de/tests/6638157</a><br>
<a href="https://openqa.suse.de/tests/6625293" class="external">https://openqa.suse.de/tests/6625293</a></p>
<p>The first job has some interesting output in <a href="https://openqa.suse.de/tests/6638157/logfile?filename=autoinst-log.txt" class="external">autoinst-log.txt</a>:</p>
<pre><code>[2021-08-03T07:24:58.610 CEST] [debug] no change: 0.5s
[2021-08-03T07:25:03.632 CEST] [debug] WARNING: check_asserted_screen took 4.02 seconds for 35 candidate needles - make your needles more specific
[2021-08-03T07:25:03.632 CEST] [debug] no match: -0.5s, best candidate: linux-login-20181005 (0.29)
*** Error in `/usr/bin/isotovideo: backen': free(): invalid pointer: 0x00005560f6795e00 ***
[2021-08-03T07:25:05.336 CEST] [debug] backend process exited: 0
[2021-08-03T07:25:05.336 CEST] [debug] stopping command server 30808 because test execution ended
</code></pre>
<p>The other job does not show any obvious error in <a href="https://openqa.suse.de/tests/6625293/logfile?filename=autoinst-log.txt" class="external">the log</a>:</p>
<pre><code>[2021-07-31T07:21:58.852 CEST] [debug] no change: 1785.4s
[2021-07-31T07:22:01.325 CEST] [debug] backend process exited: 0
[2021-07-31T07:22:01.326 CEST] [debug] stopping command server 21557 because test execution ended
</code></pre>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<ul>
<li>Reproduce locally</li>
<li>Extend <code>t/01-test_needle.t</code> to reproduce this case</li>
<li>Have the test create and destroy multiple needs in a loop</li>
<li>Try using an optimized build for tinycv (e.g. via cmake argument <code>-DCMAKE_BUILD_TYPE=RelWithDebInfo</code>, see <a href="https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html" class="external">https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html</a>) if the problem is not reproducible</li>
<li>Provoke more threading in opencv</li>
<li>Investigate memory-handling on the Perl side, passed to opencv, in baseclass (check os-autoinst readme)</li>
</ul>
openQA Project - action #94531 (New): OpenQA worker randomly skips uploading artefacts for whole ...https://progress.opensuse.org/issues/945312021-06-23T08:21:44ZMDouchamartin.doucha@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Once in a while, some jobs randomly end up with one or more modules missing all screenshots and console output. The boxes do appear in OpenQA web UI but only show <code>Unable to read foo-123.txt.</code> or blank box instead of a screenshot:<br>
<a href="https://openqa.suse.de/tests/6308588#step/cn_pec_sh/1" class="external">https://openqa.suse.de/tests/6308588#step/cn_pec_sh/1</a></p>
<p>Worker-log.txt shows that the missing files were not uploaded at all. The worker uploaded all artefacts for <code>update_kernel</code> and <code>install_ltp</code> but there's not a single line with <code>Uploading artefact cn_pec_sh-*.txt</code> or <code>Uploading artefact shutdown_ltp-*.txt</code> (except for log assets uploaded by calling <code>upload_logs()</code> in the test itself):<br>
<a href="https://openqa.suse.de/tests/6308588/logfile?filename=worker-log.txt" class="external">https://openqa.suse.de/tests/6308588/logfile?filename=worker-log.txt</a></p>
<p>I've seen this happen randomly multiple times, usually it's just one module in the middle of a test run. Everything before it and after it gets uploaded correctly.</p>
<a name="Steps-to-reproduce"></a>
<h2 >Steps to reproduce<a href="#Steps-to-reproduce" class="wiki-anchor">¶</a></h2>
<ul>
<li>Look for jobs with test modules steps that include <code>Unable to read</code></li>
</ul>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>another job in the same scenario as the original one shows correct expected data in steps, <a href="https://openqa.suse.de/tests/6312792#step/cn_pec_sh/1" class="external">https://openqa.suse.de/tests/6312792#step/cn_pec_sh/1</a> shows</p>
<pre><code># wait_serial expected: "# "
# Result:
#
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> test module steps are uploaded again for openqa.suse.de LTP cases in general</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Find fail ratio</li>
<li>Try to reproduce problem locally</li>
<li>Find out what files the openQA worker should try to upload</li>
</ul>
<a name="Out-of-scope"></a>
<h2 >Out of scope<a href="#Out-of-scope" class="wiki-anchor">¶</a></h2>
<ul>
<li>If we find a problem in the custom LTP runner don't try to fix that on openQA side but have it be fixed within os-autoinst-distri-opensuse</li>
</ul>
openQA Project - action #92533 (New): Module-centric test result overviewhttps://progress.opensuse.org/issues/925332021-05-11T15:21:55ZMDouchamartin.doucha@suse.com
<p>In response to the discussion about <a href="https://confluence.suse.com/display/~vpelcak/Draft+-+Change+in+openQA+Review" class="external">OpenQA review process changes</a>, I'd like to propose a new test result overview that is module-centric. All current overviews are job-centric which makes it difficult to compare the results of a single module under different configurations.</p>
<p>Requirements:</p>
<ul>
<li>Show all available results of a single test module on the same page</li>
<li>Renamed instances of the same Perl module will be treated as different modules but there will be quick navigation links between them</li>
<li>Filtering and easily configurable grouping by standard OpenQA job filters (distri, arch, flavor, etc.)</li>
<li>Filtering by module result (passed/failed/softfailed/skipped/none)</li>
<li>Result grouping by test version (package version or Git commit)</li>
<li>Option to show only the latest results (per job group/build) or everything</li>
<li>Quick link to parent OpenQA job from each module result</li>
</ul>
openQA Project - action #81142 (New): VNC console corruptionhttps://progress.opensuse.org/issues/811422020-12-17T11:07:10ZMDouchamartin.doucha@suse.com
<p>It appears that issue <a class="issue tracker-4 status-3 priority-3 priority-lowest closed behind-schedule" title="action: VNC console corruption on aarch64 (Resolved)" href="https://progress.opensuse.org/issues/61994">#61994</a> is back, this time on PPC64LE. LTP tests fail to boot because switching from boot animation to login screen corrupts VNC frame buffer and needles fail to match.<br>
<a href="https://openqa.suse.de/tests/5187741#step/boot_ltp/9" class="external">https://openqa.suse.de/tests/5187741#step/boot_ltp/9</a><br>
<a href="https://openqa.suse.de/tests/5187758#step/boot_ltp/8" class="external">https://openqa.suse.de/tests/5187758#step/boot_ltp/8</a></p>
openQA Project - action #70615 (New): Calling select_serial_terminal() twice on s390x svirt backe...https://progress.opensuse.org/issues/706152020-08-27T15:23:01ZMDouchamartin.doucha@suse.com
<p>When the same job calls <code>select_serial_terminal()</code> twice on s390x svirt worker (e.g. once before and once after reboot), the test will crash with the following error:</p>
<pre><code># wait_serial expected: qr/login:\s*$/ui
# Result:
Script started, file is /tmp/serial_terminal.txt.DjErjAe114GKpV_a
Connected to domain openQA-SUT-3
Escape character is ^]
error: operation failed: Active console session exists for this domain
CONSOLE_EXIT_DjErjAe114GKpV_a: 1
Script done, file is /tmp/serial_terminal.txt.DjErjAe114GKpV_a
</code></pre>
<hr>
<pre><code># Test died: Failed to wait for login prompt at /var/lib/openqa/cache/openqa.suse.de/tests/sle/lib/serial_terminal.pm line 113.
</code></pre>
<p><a href="https://openqa.suse.de/tests/4600947#step/install_klp_product/32" class="external">https://openqa.suse.de/tests/4600947#step/install_klp_product/32</a></p>
<p>Calling <code>select_serial_terminal()</code> multiple times works fine on other archs.</p>
openQA Project - action #70612 (New): better error handling in testapi function script_output (wa...https://progress.opensuse.org/issues/706122020-08-27T14:16:53ZMDouchamartin.doucha@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>I've just spent 2 hours staring into code trying to figure out why <code>get_patches()</code> in lib/qam.pm rejected an update that has the right incident ID and is marker as needed.<br>
<a href="https://openqa.suse.de/tests/4596773#step/update_kernel/63" class="external">https://openqa.suse.de/tests/4596773#step/update_kernel/63</a></p>
<p>Then I've noticed that the leading output marker is malformed due to VNC typing issue so <code>script_output()</code> simply returned an empty string to <code>get_patches()</code>.</p>
<p>When <code>script_output()</code> fails to parse the output, it shouldn't silently return an empty string. Suggestion: It should throw an exception.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> Parsing errors in script_output can be easily distinguished from a false boolean result from the internal called script command</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Review and potentially extend os-autoinst t/03-testapi.t for how script_output behaves on an error like lost characters leading to unparseable responses</li>
</ul>
openQA Project - action #69700 (New): Predefined QEMU hardware profiles in os-autoinsthttps://progress.opensuse.org/issues/697002020-08-07T10:15:47ZMDouchamartin.doucha@suse.com
<p>We've recently had a <a href="https://bugzilla.suse.com/show_bug.cgi?id=1174887" class="external">regression</a> that made our kernels unbootable in QEMU VMs created in virt-manager. The regression was missed by OpenQA tests because os-autoinst uses VMs with minimal hardware configuration which didn't trigger the bug.</p>
<p>We should define multiple QEMU hardware profiles (named sets of extra device options for QEMU) which can then be selected through job settings. The hardware profiles don't need to cover every possible combination of devices, it'll be enough if each device model appears in them at least once. One of the profiles should be as close to virt-manager defaults as possible. Then it'll be sufficient to boot the existing LTP jobs on different hardware profiles. We don't need any extra tests beyond checking that the kernel is bootable.</p>
<p>Example profile that would trigger the regression:</p>
<pre><code>-machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off
-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1
-device pcie-pci-bridge,id=pci.9,bus=pci.2,addr=0x0
</code></pre> openQA Tests - action #64285 (New): [qe-core][qem] Aggregate tests with GM base imagehttps://progress.opensuse.org/issues/642852020-03-06T16:39:37ZMDouchamartin.doucha@suse.com
<p>This is a test scenario designed to detect weak dependency breakage which caused certificate issues on SLE-12. <a href="https://bugzilla.suse.com/show_bug.cgi?id=1165915" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1165915</a></p>
<p>Scenario:</p>
<ol>
<li>Start with GM base image of target SLE (only packages from GM pool)</li>
<li>Collect package names from incident repos</li>
<li>Install corresponding packages from GM pool repos</li>
<li>Enable both update repos <strong>AND</strong> incident repos</li>
<li>Do full system update</li>
<li>Run package-specific tests</li>
</ol>
<p>If you don't install old packages from GM pool first, zypper will order packages correctly through transitive dependencies. We're specifically trying to break transitive dependencies here.</p>
<p>If you separate system update from incident installation (splitting step 4), you may accidentally force correct ordering of transitive dependencies through release timing. In that case, dependency bugs will show up only if the packages with broken weak dependency both end up in testing queue at the same time (not guaranteed), of after both have been released (oh sh*t).</p>