openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-02-07T13:33:23ZopenSUSE Project Management Tool
Redmine openQA Tests - action #155083 (In Progress): [qe-core] schedule openssl_nodejs on all SLE versionshttps://progress.opensuse.org/issues/1550832024-02-07T13:33:23Zmgrifalconi
<p>Right now it is not running on SLE15 SP4 and SP5</p>
<p>Test runs fail on the same tests for both node versions:<br>
15 SP4 <a href="https://openqa.suse.de/tests/13450430#step/openssl_nodejs/9" class="external">https://openqa.suse.de/tests/13450430#step/openssl_nodejs/9</a> (full log: <a href="https://openqa.suse.de/tests/13450430/logfile?filename=serial_terminal.txt" class="external">https://openqa.suse.de/tests/13450430/logfile?filename=serial_terminal.txt</a>)<br>
15 SP5 <a href="https://openqa.suse.de/tests/13450434#step/openssl_nodejs/9" class="external">https://openqa.suse.de/tests/13450434#step/openssl_nodejs/9</a> (full log: <a href="https://openqa.suse.de/tests/13450434/logfile?filename=serial_terminal.txt" class="external">https://openqa.suse.de/tests/13450434/logfile?filename=serial_terminal.txt</a>)</p>
<pre><code>15 SP4
Some tests have failed:
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-multi-key.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-client-renegotiation-13.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-client-getephemeralkeyinfo.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-sni-option.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-client-verify.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-client-mindhsize.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-dhe.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-sni-server-client.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-server-verify.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-cert-regression.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-peer-certificate-encoding.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-client-auth.js
Node v18.18.2-150400.9.15.1 Test test/parallel/test-tls-multiple-cas-as-string.js
15 SP5
Some tests have failed:
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-multi-key.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-client-renegotiation-13.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-client-getephemeralkeyinfo.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-sni-option.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-client-verify.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-client-mindhsize.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-dhe.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-sni-server-client.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-server-verify.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-cert-regression.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-peer-certificate-encoding.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-client-auth.js
Node v20.8.1-150500.11.3.1 Test test/parallel/test-tls-multiple-cas-as-string.js
</code></pre> openQA Tests - action #154039 (Blocked): [qe-core] [sporadic][timeout] test fails in mdadmhttps://progress.opensuse.org/issues/1540392024-01-22T13:10:15Zmgrifalconi
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Seems sporadic but getting frequent today, might be worth to increase some timeout at least.</p>
<p>openQA test in scenario sle-15-SP4-Server-DVD-Incidents-TERADATA-x86_64-mau-extratests2@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13308075/modules/mdadm/steps/7" class="external">mdadm</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>. Run console tests against aggregated test repo</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/13307913" class="external">:31365:tomcat</a></p>
<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/13307450" class="external">:32173:MozillaFirefox</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-TERADATA&machine=64bit&test=mau-extratests2&version=15-SP4" class="external">latest</a></p>
QA - action #153886 (New): SMELT incidents and Release Requests IDs are not unique and may interf...https://progress.opensuse.org/issues/1538862024-01-18T13:58:20Zmgrifalconi
<p>I would like to raise 2 issues (to be verified) about the current approval process of maintenance updates:</p>
<ul>
<li><p>SMELT Incidents ID can be reused for multiple Release Requests and what the process uses right now is the incident ID to tag a test that is crucial for the RR approval. Now the bot/dashboard combo uses a workaround of deleting some openqa results (from dashboard DB) to prevent issues (see <a href="https://github.com/openSUSE/qem-dashboard/pull/78/files" class="external">https://github.com/openSUSE/qem-dashboard/pull/78/files</a> ) but this makes the bot approval logic complex and shared between bot and dashboard code. Would be nice to switch from SMELT ID to IBS RR ID (or just add the RR on top) to resolve the issue at the origin.</p></li>
<li><p>RR are not unique either, but in a different way: RR can be revoked and then reopen (maybe with different content to test? to be checked). I know the bot recognize (some) changes and re-triggers incident tests, but what about aggregates? Is there a chance they could be wrongly considered for approval decision? Also incident channels could be changed while the incident/RR combo is being tested causing some confusion on bot side. If this proves to be a real issue, a solution idea would be to make sure test results related to older 'version' of a RR are not considered and the bot waits for new ones. Maybe add to SMELT-ID/RR combo, also a timestamp of smelt-incident/ibs-rr latest change?</p></li>
</ul>
<p>I can expect the valid argument that these are rare corner cases, but we should also consider that we are here to catch corner cases. Complex updates that gets modified while being tested should get enhanced attention and not reduced IMO.</p>
openQA Infrastructure - action #151570 (New): [qe-core] Cleanup openQA jobgroupshttps://progress.opensuse.org/issues/1515702023-11-28T07:41:52Zmgrifalconi
<p>On both openqa.suse.de and openqa.opensuse.org we have many old job groups that are unused but were never deleted, likely due to the missing option in the web-ui (see <a href="https://progress.opensuse.org/issues/57170" class="external">https://progress.opensuse.org/issues/57170</a>).</p>
<p>I understand there might be little performance impact on leaving them be, but if there is no business reason to keep them I think is time to do some cleanup.</p>
<p>AC1: Find out if old job groups can be deleted or there is some reason to keep them<br>
AC2: Check how difficult would be to implement the delete button in the ui<br>
AC3: Clean up what is possible</p>
openQA Tests - action #121153 (New): [qe-core] remove qe_run testshttps://progress.opensuse.org/issues/1211532022-11-30T10:54:08Zmgrifalconi
<p>While deprecation of qe_run did not progress <a href="https://progress.opensuse.org/issues/99657" class="external">https://progress.opensuse.org/issues/99657</a> , turns out we have still some tests in our bucket using it:</p>
<p><a href="https://openqa.suse.de/tests/10055095#" class="external">https://openqa.suse.de/tests/10055095#</a><br>
<a href="https://openqa.suse.de/tests/10055092/modules/userspace_nfs/steps/1/src" class="external">https://openqa.suse.de/tests/10055092/modules/userspace_nfs/steps/1/src</a></p>
<p>We should either remove the tests or convert them as a normal perl module.</p>
<p>Then we should either:</p>
<ul>
<li>decommission qe_run and remove the framework entirely</li>
<li>find some squads that is still willing to use it and hand over the responsibility for it</li>
</ul>
openQA Tests - action #117622 (Resolved): [qe-core] Unable to clone Git repository for wheelshttps://progress.opensuse.org/issues/1176222022-10-06T09:30:52Zmgrifalconi
<p><a href="https://openqa.suse.de/tests/9668977#" class="external">https://openqa.suse.de/tests/9668977#</a></p>
<pre><code>[2022-10-06T02:01:46.761898+02:00] [info] ::: OpenQA::Isotovideo::Utils::checkout_git_repo_and_branch: Cloning git URL 'https://github.com/Zaoliang/functional_wheel'
[2022-10-06T02:01:52.973889+02:00] [debug] Cloning into 'functional_wheel'...
fatal: unable to access 'https://github.com/Zaoliang/functional_wheel/': OpenSSL SSL_connect: Connection reset by peer in connection to github.com:443
</code></pre>
<p>Regardless of the cause of the issue, I am against using personal repos for test. What happens if owner changes team or company or simply on vacation? <br>
It's great for trying things out but when using on production, it should go into company owned github accounts, and squad owned repos.</p>
<a name="Acceptance-Criteria"></a>
<h4 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h4>
<ol>
<li><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15336" class="external">#os-autoinst/os-autoinst-distri-opensuse/15336</a> is reverted (this removes the urgency of this ticket)</li>
<li>Fork <a href="https://github.com/Zaoliang/functional_wheel" class="external">https://github.com/Zaoliang/functional_wheel</a> into <a href="https://github.com/os-autoinst/test-core-modules" class="external">https://github.com/os-autoinst/test-core-modules</a> cleanning up unnecesary files (i.e only lib/**.pm should stay)</li>
</ol>
openQA Tests - action #113351 (Resolved): [qe-sap] test fails in sys_param_checkhttps://progress.opensuse.org/issues/1133512022-07-07T11:27:04Zmgrifalconi
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Fails in multiple incident tests, blocking update approval</p>
<p>openQA test in scenario sle-15-SP4-Server-DVD-Incidents-x86_64-mau-sles-sys-param-check@64bit-2gbram fails in<br>
<a href="https://openqa.suse.de/tests/9084923/modules/sys_param_check/steps/38" class="external">sys_param_check</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p><a href="https://gitlab.suse.de/qa-css/sys-param-check" class="external">https://gitlab.suse.de/qa-css/sys-param-check</a></p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/9084331" class="external">:24921:tiff</a></p>
<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/9083892" class="external">:24930:sg3_utils</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&machine=64bit-2gbram&test=mau-sles-sys-param-check&version=15-SP4" class="external">latest</a></p>
openQA Tests - action #106633 (Resolved): [qe-core][productchange] test fails in libreoffice_main...https://progress.opensuse.org/issues/1066332022-02-11T08:49:37Zmgrifalconi
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Missing from favorites, might be a bug </p>
<p>openQA test in scenario sle-15-SP3-Desktop-DVD-Updates-x86_64-qam-regression-documentation@64bit fails in<br>
<a href="https://openqa.suse.de/tests/8139970/modules/libreoffice_mainmenu_favorites/steps/4" class="external">libreoffice_mainmenu_favorites</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/8122377" class="external">20220209-1</a></p>
<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/8118328" class="external">20220208-1</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=Desktop-DVD-Updates&machine=64bit&test=qam-regression-documentation&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #101882 (New): [qe-core] aarch64 workers: test fails in patch_and_reboothttps://progress.opensuse.org/issues/1018822021-11-03T10:17:47Zmgrifalconi
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Test expects to find the bootloader needle ( <a href="https://openqa.suse.de/tests/7588098#step/patch_and_reboot/52" class="external">https://openqa.suse.de/tests/7588098#step/patch_and_reboot/52</a> ) but somehow it is not picked by openqa and it fails.<br>
We could at the same time check for the login needle and skip the need of the bootloader if not found I suppose.</p>
<p>openQA test in scenario sle-15-Server-DVD-Updates-aarch64-qam-gnome@aarch64-virtio fails in<br>
<a href="https://openqa.suse.de/tests/7596208/modules/patch_and_reboot/steps/61" class="external">patch_and_reboot</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/7594031" class="external">20211103-1</a></p>
<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/7588098" class="external">20211102-1</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=aarch64&distri=sle&flavor=Server-DVD-Updates&machine=aarch64-virtio&test=qam-gnome&version=15" class="external">latest</a></p>
QA - action #97274 (New): qam dashboard improvement ideashttps://progress.opensuse.org/issues/972742021-08-20T06:48:13Zmgrifalconi
<p>Hello, doing openQA review I always used smelt comments to find out which test run needs to be checked to approve an update.</p>
<p>Ideally approval is automated, but when a single test fails (out of dozens/hundreds) it still needs some manual work to decide if such failures can be ignored for that particular test.</p>
<p>I won't mention crosscheck aggregate runs with precedent days (see <a href="https://progress.opensuse.org/issues/97118" class="external">https://progress.opensuse.org/issues/97118</a>).</p>
<p>These are the current issues I found while using the dashboard for my week of review:</p>
<ul>
<li><strong>Sorting order</strong>: I like to sort on smelt the priority or due date to have an idea on the situation. Neither of which is available. Incidents are sorted by incident ID, which I do not care</li>
<li><strong>Missing Release Request ID</strong>: If I am given only a RR ID, I must go to smelt to find the incident and back to the dashboard.</li>
<li><strong>Result History</strong>: I can only see latest results, so I find more painful to crosscheck different days, but I would be happier to see such think automated (see other poo linked earlier). In the meantime though, it is just more painful than before. I also have a good overview of the situation near the end of the day, because in the morning all runs are still ongoing and cannot do review based on yesterday's results.</li>
<li><strong>Development Job Groups</strong>: such job groups are not ignored, also some test groups will fit in. This creates some confusion and time wasted.</li>
</ul>
<p>Extra thought: <br>
The dashboard and smelt might be duplicating some work. Why not having a link in smelt to the list of related tests on the dashboard? I would be using the indexing/priority/informations on smelt and then go on the dashboard to check tests, possibly with result history.<br>
What I am basically asking for is the same features as smelt comments, whichever implementation is used. </p>
QA - coordination #97121 (New): [epic] enable qem-bot comments on IBS (was: enable qa-maintenance...https://progress.opensuse.org/issues/971212021-08-18T12:25:23Zmgrifalconi
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>As a maintenance release coordinator I am being notified if there is any failing openQA test blocking automatic approval of a SLE maintenance update</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> As soon as testing for an individual release request is finished and if there is at least one failing openQA test a comment is written in IBS informing about the failing openQA tests</li>
<li><strong>AC2:</strong> If there is no failing openQA test related to an individual release request no comment is written</li>
<li><strong>AC3:</strong> Only a single comment is ever written on a release request</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Within qem-bot we already have the feature to send out comments but it seems so far it does not look at the state of openQA jobs so it writes a comment for all release requests whenever triggered which means informing even about all currently running jobs. Maybe the next best task is to actually look at the state and only inform about failing openQA tests</li>
<li>Think about moving the trigger point of sending a comment into the approval step or something so when no automatic approval is done instead a comment is written</li>
<li>Ensure that only a single comment is written, not multiple whenever qem-bot is called</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Original motivation: <br>
While the qem dashboard is agreed to not yet be productive, smelt comments are very useful while doing manual approval of updates.</p>
<p>I would like to have such resource back, at least until <a href="https://progress.opensuse.org/issues/97118" class="external">https://progress.opensuse.org/issues/97118</a> <a class="issue tracker-4 status-4 priority-4 priority-default child" title="action: enhance bot automatic approval: check multiple days (Feedback)" href="https://progress.opensuse.org/issues/97118">#97118</a> is sorted out.</p>
openQA Tests - action #97007 (Blocked): [qa-core] test fails in dracut_enhancedhttps://progress.opensuse.org/issues/970072021-08-17T07:31:04Zmgrifalconi
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP3-Server-DVD-Updates-x86_64-qam-dracut-systemd@64bit fails in<br>
<a href="https://openqa.suse.de/tests/6867197/modules/dracut_enhanced/steps/34" class="external">dracut_enhanced</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Maintainer: <a href="mailto:emiura@suse.com">emiura@suse.com</a></p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/6838543" class="external">20210813-1</a></p>
<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/6652918" class="external">20210805-1</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-Updates&machine=64bit&test=qam-dracut-systemd&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #95724 (Resolved): [qe-core] move vim out of installation testshttps://progress.opensuse.org/issues/957242021-07-20T11:58:23Zmgrifalconi
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Broken screenshot (see bottom left) causes vim test to sporadically fail.<br>
It is also painful to restart since it takes 2h each time. We could consider splitting this into installation and other test runs that boots from a disk.</p>
<p>openQA test in scenario sle-12-SP5-Server-DVD-Incidents-Minimal-aarch64-qam-minimal-full@aarch64 fails in<br>
<a href="https://openqa.suse.de/tests/6492517/modules/vim/steps/6" class="external">vim</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>minimal = base pattern, minimal (enhanced base) pattern are additional convenience paclkages</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/6484472" class="external">:20468:kernel-ec2</a></p>
<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/6464767" class="external">:20260:dbus-1</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=aarch64&distri=sle&flavor=Server-DVD-Incidents-Minimal&machine=aarch64&test=qam-minimal-full&version=12-SP5" class="external">latest</a></p>
openQA Tests - action #95365 (Resolved): [qe-core] move ncurses out of installation testshttps://progress.opensuse.org/issues/953652021-07-12T06:52:47Zmgrifalconi
<p>Currently ncurses test runs as part of many installation tests.</p>
<p>Ideally, installation test should only install and run some checks strictly related to installation.<br>
The reason is to give less chances possible for such run to fail, because a lot of other runs will depend on the installation and a retry of installation takes a long time.</p>
<p>Consider moving it on test suite that runs from a disk.</p>
<ul>
<li>Find out where the test runs</li>
<li>Propose alternative on non-installation test suites</li>
<li>move it</li>
<li>check for other candidates to be moved and create new poo#</li>
</ul>
openQA Tests - action #95362 (Workable): [qe-core] make zypper_call use serial terminal regardles...https://progress.opensuse.org/issues/953622021-07-12T06:46:59Zmgrifalconi
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Anything that has to do with aarch64, or any architecture for that matter in terms of calling things like zypper_call, can be shifted to serial terminal.</p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Modify zypper_call to always use serial terminal, then switch back to what it was using originally (testapi has <code>current_console</code> to get, the current console :))</li>
<li>Add a parameter to support backwards compatibility, to disable such feature in case of need (such as no_console_switch=1), assume that if the parameter is not set and VIRTO_CONSOLE=1 is set, the switch is enabled by default)</li>
<li>Advertise change in proper channels via RFC in os-autoinst-distri-opensuse (openqa, qa-sle ML, link in #testing in RC/Slack)</li>
</ul>