openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-02-15T18:12:36ZopenSUSE Project Management Tool
Redmine openQA Project - action #124652 (Resolved): gtk glitch not showing dialog window decoration on op...https://progress.opensuse.org/issues/1246522023-02-15T18:12:36Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>During our graphical YaST tests we (the qe-yam team) encounter a type of graphic glitch where the screen is not properly refreshed.<br>
Examples can be seen <a href="https://openqa.suse.de/tests/10436703#step/iscsi_client/57" class="external">here</a> and <a href="https://openqa.suse.de/tests/9680782#step/yast2_control_center/96" class="external">here</a></p>
<p>This behavior is sporadic but widespread enough that it has forced qe-yam to apply <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15889" class="external">workarounds</a> to a number of our tests.<br>
Because the conditions allowing the workarounds are not always consistent, we have interest in the root of the issue getting resolved.<br>
Our <a href="https://bugzilla.suse.com/show_bug.cgi?id=1204176" class="external">latest bug entry</a> on the matter has been tagged as WONTFIX because we (qe-yam and the YaST developers) have not found a way to reproduce this glitch outside of the openQA environment.</p>
<p>latest: <a href="https://openqa.suse.de/tests/10499467#step/yast2_lan_restart_vlan/19">https://openqa.suse.de/tests/10499467#step/yast2_lan_restart_vlan/19</a> (glitch does not happen on yast2_control_center on last build but can be seen elsewhere)<br>
last good: <a href="https://openqa.suse.de/tests/5900202#step/yast2_control_center/94">https://openqa.suse.de/tests/5900202#step/yast2_control_center/94</a></p>
<a name="Scope"></a>
<h3 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h3>
<p>aarch64, s390x, x86_64 on SLE 15-SP4 and SLE 15-SP5 (issue is not exclusive on qemu)</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> The graphic glitch does not appear anymore in tests</li>
</ul>
<a name="Problem"></a>
<h2 >Problem<a href="#Problem" class="wiki-anchor">¶</a></h2>
<ul>
<li><p><strong>H1</strong> could be the qemu video adapter</p>
<ul>
<li><strong>H1.1</strong> <strong>REJECTED</strong> could be the specific choice of qemu video adapter</li>
<li><em>E1.1-1</em> <em>DONE</em> Try out the reproducing openQA test with different qemu video adapters -> <em>O1.1-1-1</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-16">#124652#note-16</a> different video
adapters reproduced the same issue</li>
<li><strong>H1.2</strong> maybe can not be reproduced with using special qemu video adapter settings</li>
</ul></li>
<li><p><strong>H2</strong> <strong>REJECTED</strong> only happens in older SLE versions => Current SLE15SP5 affected the same</p>
<ul>
<li><em>E2-1</em> <em>DONE</em> Run the equivalent openQA test on SLE </li>
<li><em>O2-1-1</em> issue observed on SLE15SP4-build31.2+ <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-3">#124652#note-3</a></li>
<li><em>O2-1-2</em> 0/100 failures on SLE15SP3+maintenance updates <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-25">#124652#note-25</a></li>
<li><em>E2-2</em> <em>DONE</em> Run the equivalent openQA test on current Tumbleweed -> <em>O2-2-1</em> Tumbleweed does not reproduce the problem, see <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-26">#124652#note-26</a></li>
<li><em>E2-3</em> <em>DONE</em> Run the equivalent openQA test on current SLE15SP5 -> <em>O2-3-1</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-32">#124652#note-32</a> 5/101 (yast2_security) fails <a href="https://openqa.suse.de/tests/overview?distri=sle&build=glitch_investigation_SP5&version=15-SP5" class="external">SLE15SP5@OSD</a></li>
<li><strong>H2.1</strong> <strong>ACCEPTED</strong> only happens in older SLE versions with newer maintenance updates</li>
<li><em>E2.1-1</em> <em>DONE</em> Run openQA test on SLE15-SP4 -> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-23">#124652#note-23</a> 97% fail rate iscsi_server on SLE15-SP4</li>
<li><em>E2.1-2</em> <em>DONE</em> From <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-24">#124652#note-24</a> Run openQA test on SLE15-SP3 with state of maintenance update from 2 years ago ("last good" <a href="https://openqa.suse.de/tests/5900202#step/yast2_control_center/94">https://openqa.suse.de/tests/5900202#step/yast2_control_center/94</a> from #Motivation) -> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-36">#124652-36</a> 0/100 failures on SLE15SP3GM; 0/100 failures on SLE15SP2+updates -> accept <em>H2.1</em></li>
</ul></li>
<li><p><strong>H3</strong> <strong>ACCEPTED</strong> can only be reproduced in openQA</p>
<ul>
<li><em>E3-1</em> <em>DONE</em> try to reproduce manually -> no one could reproduce manually</li>
<li><strong>H3.1</strong> <strong>REJECTED</strong> can be reproduced on openqa.suse.de regardless of OS version or variant</li>
<li><em>E3.1-1</em> <em>DONE</em> Run openSUSE openQA test on openqa.suse.de -> <em>O3.1-1-1</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-32">#124652#note-32</a> 0/101 fails <a href="https://openqa.suse.de/tests/overview?distri=opensuse&build=glitch_investigation_tw&version=Tumbleweed" class="external">Tumbleweed@OSD</a> + 0/101 <a href="https://openqa.suse.de/tests/overview?distri=opensuse&build=glitch_investigation_leap_sp4&version=15.4" class="external">Leap15.4@OSD</a> + 0/100 <a href="https://openqa.suse.de/tests/overview?distri=opensuse&version=Leap15.5&build=glitch_investigation_leap_sp5" class="external">Leap15.5@OSD</a> vs. 5/101 fails <a href="https://openqa.suse.de/tests/overview?distri=sle&build=glitch_investigation_SP5&version=15-SP5" class="external">SLE15SP5@OSD</a></li>
</ul></li>
<li><p><strong>H4</strong> <strong>ACCEPTED</strong> The test module(s) "iscsi_server/client" are most prone to fail, also shows in other yast modules</p>
<ul>
<li><em>E4-1</em> <em>DONE</em> Gather statistics for different yast modules -></li>
<li><em>O4-1-1</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-11">#124652#note-11</a> the problem was referenced for different modules, e.g. iscsi_server and yast2_security but no clear statistics</li>
<li><em>O4-1-2</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-23">#124652#note-23</a> 97-99% fail rate iscsi_server on SLE15-SP4/5 vs. <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-32">#124652#note-32</a> 5% yast2_security on SLE15-SP5</li>
</ul></li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>It looks like window decorations are missing from the dialog</li>
<li>The emulated graphics adapter might be causing problems with the window manager</li>
<li>Research what options could be used with the graphics emulation in qemu</li>
<li>Identify the underlying parameter(s) in the openQA environment that can cause this graphical glitch.</li>
<li>Find a last good? We couldn't find one easily?</li>
<li>could be a VNC-related issue? Missing borders may occur there</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p><a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=yast2_gui&version=15-SP5" class="external">Link to latest</a></p>
openQA Project - action #122608 (Resolved): exit code of shell command not received by script_runhttps://progress.opensuse.org/issues/1226082023-01-02T18:41:03Zgeorggkioulis@suse.com
<p>Occasionally, <code>script_run</code> (and <code>assert_script_run</code>) do not receive the exit code from the shell command, even though the command has exited, resulting in a timeout.<br>
This has been noticed on s390x-kvm <a href="https://openqa.suse.de/tests/9951916#step/logs_from_installation_system/6" class="external">here</a> where the ping command returns but still <code>script_run</code> times out.<br>
It is also obvious in <a href="https://openqa.suse.de/tests/10244897#step/logs_from_installation_system/7" class="external">this example</a> where <code>assert_script_run</code> times out, despite the fact that the <code>ls</code> command has returned.<br>
The issue is very sporadic and not easy to debug.</p>
openQA Infrastructure - action #102167 (Resolved): Disk monitoring for s390x z/VM backendhttps://progress.opensuse.org/issues/1021672021-11-09T13:47:32Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>There are multiple recent occasions of openQA s390x z/VM tests failing due to <code>Disk or file space is full</code>, eg in scenario sle-15-SP4-Online-s390x-allpatterns@s390x-zVM-vswitch-l3, on <a href="https://openqa.suse.de/tests/7618985/modules/bootloader_start/steps/30" class="external">bootloader_start</a></p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<p><strong>AC1</strong>: Monitor disk space of the z/VM hypervisor<br>
<strong>AC2</strong>: Trigger a manual or automatic clean-up process</p>
<a name="Other-Suggestions"></a>
<h2 >Other Suggestions<a href="#Other-Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Increase storage size</li>
</ul>
qe-yam - action #99573 (Rejected): Investigate failure of LVM activationhttps://progress.opensuse.org/issues/995732021-09-30T15:36:18Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-aarch64-activate_encrypted_volume+import_users@aarch64 fails in<br>
<a href="https://openqa.suse.de/tests/7274219/modules/skip_install_addons/steps/1" class="external">skip_install_addons</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/7269640" class="external">43.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/7217928" class="external">39.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=Online&machine=aarch64&test=activate_encrypted_volume%2Bimport_users&version=15-SP4" class="external">latest</a></p>
qe-yam - action #99570 (Rejected): Beta distribution popup appears after access_beta_distributionhttps://progress.opensuse.org/issues/995702021-09-30T15:28:09Zgeorggkioulis@suse.com
<p>The beta distribution popup delays to appear, probably due to changes introduced in the recent build.<br>
This results in the failing of the module after the <code>access_beta_distribution</code> module, <code>install_SLES</code>.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-ppc64le-RAID5@ppc64le-no-tmpfs fails in<br>
<a href="https://openqa.suse.de/tests/7277663/modules/install_SLES/steps/2" class="external">install_SLES</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>. Maintainer: slindomansilla, jrauch</p>
<p>Installation of RAID5 using expert partitioner</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/7277663" class="external">43.1</a> (current job)</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/7218198" class="external">39.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=ppc64le&distri=sle&flavor=Online&machine=ppc64le-no-tmpfs&test=RAID5&version=15-SP4" class="external">latest</a></p>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>If the BETA test variable is 1, wait for the Beta Distribution popup within a corresponding duration.</p>
qe-yam - action #99567 (Rejected): aarch64 job takes more than 2h and times outhttps://progress.opensuse.org/issues/995672021-09-30T14:06:05Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h1 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h1>
<p>The <a href="https://openqa.suse.de/tests/7275652" class="external">aarch64 select_modules_and_patterns+registration</a> job seems to now take occasionally more than two hours to complete.</p>
<p>A suggested point of action would be to make MAX_JOB_TIME more than the current 7200 seconds for this specific testsuite.</p>
qe-yam - action #99555 (Closed): Investigate x11_yast pattern being installed unexpectedelyhttps://progress.opensuse.org/issues/995552021-09-30T11:52:54Zgeorggkioulis@suse.com
<p>It seems that in Build43.1 pattern <code>x11_yast</code> is (unexpectedly) installed, alongside the other expected patterns.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Full-x86_64-select_modules_and_patterns+registration@64bit fails in<br>
<a href="https://openqa.suse.de/tests/7261284/modules/validate_installed_patterns/steps/5" class="external">validate_installed_patterns</a></p>
<p>also visible eg <a href="https://openqa.suse.de/tests/7270890#step/validate_installed_patterns/5" class="external">in this s390 job</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Full Medium installation that covers the following cases:<br>
1. Additional modules enabled using SCC (Legacy, Development Tools,<br>
Web and Scripting, Containers, Desktop Applications);<br>
2. Yast patterns installed;<br>
3. System registration is skipped during installation;<br>
4. Installation is validated by successful boot and that YaST does not<br>
report any issues;<br>
5. Registration is performed on the installed system.</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/7261284" class="external">43.1</a> (current job)</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/7217514" class="external">39.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=Full&machine=64bit&test=select_modules_and_patterns%2Bregistration&version=15-SP4" class="external">latest</a></p>
qe-yam - action #99267 (Closed): Improve validate_multipath modulehttps://progress.opensuse.org/issues/992672021-09-24T18:01:26Zgeorggkioulis@suse.com
<p>After some recent changes in the zfcp connectivity, <code>validate_multipath</code> module is failing.</p>
<p>The main reason of the failure is that after the changes, we have two <code>wwid</code> entries instead of one. <br>
Compare the listed wwids (output at the bottom) from <a href="https://openqa.suse.de/tests/6457740#step/validate_multipath/2" class="external">this job</a> to <a href="https://openqa.suse.de/tests/7202075#step/validate_multipath/2" class="external">this one</a>.<br>
This results in the stored <code>$wwid</code> output in the <code>validate_multipath</code> module to contain two lines with two different worldwide identifiers.</p>
<p>Similarly, due to this, the output of <code>multipath -ll</code> now contains two device mapper devices instead of one.<br>
This can be seen <a href="https://openqa.suse.de/tests/7202075#step/validate_multipath/23" class="external">here</a> in contrast to <a href="https://openqa.suse.de/tests/6457740#step/validate_multipath/23" class="external">this old job</a>.</p>
<p>This setup results in two commands being susceptible to failure. </p>
<ol>
<li>The first is <code>assert_matches(qr/$wwid dm-0 $ven_pro_rev/, $topology_output, 'General topology info are not displayed properly');</code>. This of course fails because <code>$wwid</code> contains two lines of identifiers corresponding to the two multipath maps. This is the failure seen in our zfcp jobs currently.</li>
<li>The second one is <code>validate_script_output("multipath -d -v3 | grep ^$wwid", qr/$wwid.*$name/);</code>. If the previous command would not exist the jobs would fail here because, once more, the <code>$wwid</code> parameter no longer contains only one WWID, and also because it is related to a different disk.</li>
</ol>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-s390x-zfcp@s390x-zfcp fails in<br>
<a href="https://openqa.suse.de/tests/7202075/modules/validate_multipath/steps/26" class="external">validate_multipath</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">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>. Maintainer: QE Yast, mgriessmeier</p>
<p>Installation-only test configuring an s390x ZFCP storage.</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/6950169" class="external">29.1</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: (unknown) (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=s390x&distri=sle&flavor=Online&machine=s390x-zfcp&test=zfcp&version=15-SP4" class="external">latest</a></p>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>A good middle ground solution would be to store in the <code>$wwid</code> parameter only one of the identifiers matching to a single multipath map.<br>
This would mean that both commands 1. and 2. listed on the top of the description would pass.<br>
This is not a compromise, since we will still test the validity of one multipath map (as was the case for 15-SP3, before this change had occured)</p>
openQA Tests - action #96992 (Resolved): [qe-core][samba_adcli] Track and softfail all samba_adcl...https://progress.opensuse.org/issues/969922021-08-16T13:47:30Zgeorggkioulis@suse.com
<p>The samba_adcli module fails sporadically in a multitude of different cases.</p>
<ul>
<li>Identify those cases</li>
<li>Create individual poos for those that don't have one and track them</li>
<li>Softfail the sporadic failures so that the test can run without blocking approval of updates.</li>
</ul>
openQA Tests - action #95926 (Resolved): [qe-core] Investigate if mau-qa_userspace_openssh covera...https://progress.opensuse.org/issues/959262021-07-23T12:44:21Zgeorggkioulis@suse.com
<p>We need to investigate whether <code>mau-qa_userspace_openssh</code> covers any functional test cases that are not covered by the other ssh tests currently scheduled (eg sshd).</p>
<p>If not, <code>mau-qa_userspace_openssh</code> should be unscheduled (and most probably completely remove it from the os-autoinst-distri-opensuse repo, if no other squad depends on it, as it looks to be the case)</p>
openQA Tests - action #95798 (Resolved): [qe-core] SLE 15-SP3 missing from version specific secti...https://progress.opensuse.org/issues/957982021-07-21T14:34:22Zgeorggkioulis@suse.com
<p>the following yamls are missing an entry for SLE 15-SP3 in the conditional_schedule/version_specific section:</p>
<ul>
<li>schedule/qam/common/mau-extratests1.yaml </li>
<li>schedule/qam/common/mau-extratests2.yaml</li>
<li>schedule/qam/common/mau-extratests-phub.yaml</li>
</ul>
<p>This results in a number of modules (osinfo_db, ovn, firewalld, libgcrypt, valgrind, journald_fss, openvswitch_ssl and others) not being run for SLE 15-SP3 in maintenance.</p>
<p>There would be need to add an entry for 15-SP3 and also check/report if there are any related failures in those modules.</p>
QA - action #94600 (New): [tools][mtui] Communicate reduced visibility of openQA incident related...https://progress.opensuse.org/issues/946002021-06-23T13:49:30Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>The <code>Results from openQA incidents jobs:</code> section in a maintenance update's test log shows, as one would expect, the incident jobs related to the incident that is to be tested.<br>
It can happen that engineers testing the incident fall under the impression that the openQA coverage shown in the log is the complete openQA test coverage for that incident.<br>
It should thus be communicated that the <code>openQA incident jobs</code> section does not show the complete test coverage of the incident in openQA, but only a subset of it (the other being in aggregate runs that test the incident).</p>
<p>This should clarify to the engineers that the absence of failed incident jobs in the log does not mean necessarily that there are no other failed jobs related to the incident.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> Communicate that the jobs listed in the log of an update are not the complete set of jobs that test that update</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>One suggestion could be to remove that section from the log and instead link the incident comments (eg <a href="https://maintenance.suse.de/incident/19067/#comments" class="external">https://maintenance.suse.de/incident/19067/#comments</a>) where all jobs related to that incident are listed.</li>
</ul>
openQA Tests - action #90923 (Resolved): [qe-core] Schedule userspace_systemd in SLE 15 SP3https://progress.opensuse.org/issues/909232021-04-09T12:13:30Zgeorggkioulis@suse.com
<p>A <a href="https://openqa.suse.de/tests/5793735#" class="external">userspace_systemd</a> job is running on maintenance products but not on 15 SP3.</p>
<p>There already is a qa_userspace_systemd testsuite (defined but unscheduled).</p>
<p>It is needed to verify that there are no issues running it on 15 SP3.</p>
<p>After that the job can be scheduled in the Functional Job Group</p>
openQA Tests - action #89461 (Resolved): [qe-core][systemd] qa_test_systemd fails in check-mdmonitorhttps://progress.opensuse.org/issues/894612021-03-04T08:41:41Zgeorggkioulis@suse.com
<p>testcase <code>check-mdmonitor</code> of <code>qa_test_systemd</code> package fails in sle 15-SP1 and sle 15-SP2</p>
openQA Tests - coordination #69055 (Resolved): [qe-core][qem][openvswitch][epic][sprint] Increase...https://progress.opensuse.org/issues/690552020-07-16T14:43:24Zgeorggkioulis@suse.com
<p>According to <a href="https://jira.suse.com/browse/ECO-2242" class="external">ECO-2242</a> Openvswitch will include some new packages in 15 SP2:<br>
Those will be:</p>
<ul>
<li>openvswitch-ipsec</li>
<li>openvswitch-pki</li>
<li>openvswitch-test</li>
<li>openvswitch-vtep</li>
</ul>
<p>Also there is a new set of ovn packages, those have been split into another ticket <a href="https://progress.opensuse.org/issues/70501" class="external">https://progress.opensuse.org/issues/70501</a>.</p>
<p>There is need to expand openvswitch testing to cover relevant usecases.<br>
Before implementation this will require some investigation on what scenarios to include.</p>