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>
qe-yam - action #123460 (Resolved): Provide workaround for iscsi failure bsc#1207157https://progress.opensuse.org/issues/1234602023-01-20T15:09:49Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>iscsi MU tests for 15 SP3 are <a href="https://openqa.suse.de/tests/10349912#step/iscsi_client/68" class="external">failing due to wrong return code</a> (<a href="https://bugzilla.suse.com/show_bug.cgi?id=1207157" class="external">bsc#1207157</a>)<br>
We should apply the workaround suggested <a href="https://bugzilla.suse.com/show_bug.cgi?id=1206132#c12" class="external">here</a> and softfail the tests until a fix is available.</p>
<a name="Scope"></a>
<h3 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h3>
<p>For 15 SP3 MU on Yast job group, tests</p>
<ul>
<li>mru-iscsi_{server..client}_normal_auth_backstore_fileio</li>
<li>mru-iscsi_{server..client}_normal_auth_backstore_hdd</li>
<li>mru-iscsi_{server..client}_normal_auth_backstore_lvm</li>
</ul>
<p>arch x86_64</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Apply simple soft-failure of skip on the point of failure until ticket is complete<br>
<strong>AC2</strong>: Apply workaround to <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/iscsi/iscsi_client.pm" class="external">iscsi_client</a><br>
<strong>AC3</strong>: Softfail the iscsi tests by pointing to <a href="https://bugzilla.suse.com/show_bug.cgi?id=1207157" class="external">bsc#1207157</a></p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>The workaround is simple enough.<br>
After <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/iscsi/iscsi_client.pm#L108" class="external">open-iscsi has been installed</a> we need to edit the file <code>/usr/lib/systemd/system/iscsid.service</code>.<br>
At the end of the <code>[Unit]</code> section add</p>
<pre><code>Requires=iscsid.socket
After=iscsid.socket
</code></pre>
<p>Leave the rest of the file as is.<br>
After editing the service file you will need to run <code>systemctl daemon-reload</code>.</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>
qe-yam - action #122059 (Resolved): Add AutoYaST testsuite for Tumbleweed on s390x z/VMhttps://progress.opensuse.org/issues/1220592022-12-15T15:56:34Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Kernel squad would like to have similar test suites <a href="https://openqa.suse.de/tests/10087068#dependencies" class="external">sequence</a> in Tumbleweed that what they use for SLE to run later on LTP tests. (more info on <a href="https://suse.slack.com/archives/C02CANHLANP/p1671098344384289" class="external">slack thread</a>)<br>
In SLE is used <a href="https://openqa.suse.de/tests/10086929" class="external">create_hdd_minimal_base</a>:</p>
<ul>
<li>Module selected: base, desktop, development, server</li>
<li>guided partitioning: no separate home</li>
<li>system role: gnome (shouldn't be better to select textmode?)</li>
<li>pattern: base and minimal</li>
<li>Major Linux security: none</li>
<li>disable grub timeout</li>
</ul>
<p>But this is s390x kvm, and in openSUSE there is only support for z/VM.<br>
Therefore Yam squad could provide similar auto-installation than for SLE but for this backend as Kernel squad needs something that run fast, because there is not booting snapshots for z/VM so any LTP test needs to run first the installation.</p>
<p>Starting point could be to convert in AutoYaST this interactive installation: <a href="https://openqa.opensuse.org/tests/2956964">https://openqa.opensuse.org/tests/2956964</a> :</p>
<ul>
<li>disk activation</li>
<li>system role: server</li>
<li>patterns: it could be more minimal comparing with the job above</li>
<li>disable grub timeout</li>
</ul>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>A new autoyast installation testsuite is to be created in <a href="openqa.opensuse.org/" class="external">openqa.opensuse.org</a>.<br>
Currently we run there a <a href="https://openqa.opensuse.org/tests/2954722" class="external">guided installation</a> which takes around 42 mins.<br>
Products: opensuse Tumbleweed<br>
Architectures: s390x with backend s390x (which just means z/VM, the only supported backend for s390x in o3 right now)</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Create auto-installation for Tumbleweed in s390x zVM<br>
<strong>AC2</strong>: File a bug if any is found for AutoYaST cloning or service order after booting to YaST<br>
<strong>AC3</strong>: Investigate and file a infrastructure bug if found<br>
<strong>AC4</strong>: if some blocker is found, consider as last option using libyui-rest-api, which is also fast (but not ideal to have interactive installation)</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>afir there was some issues with z/VM when booting but we will see what is the state. This is completely new area where to enable AutoYaST.</p>
qe-yam - action #119083 (Rejected): [Timebox: 3 days] Investigate how to make SUT offline on PowerVMhttps://progress.opensuse.org/issues/1190832022-10-19T13:12:21Zgeorggkioulis@suse.com
<p>Related to <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: Run offline_install+skip_registration with PowerVM (Resolved)" href="https://progress.opensuse.org/issues/116116">#116116</a></p>
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Testsuite <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=offline_install%2Bskip_registration_dev&modules=&module_re=&version=15-SP5&distri=sle&groupid=456#" class="external">offline_install+skip_registration_dev</a> on ppc64le in development group is similar to <a href="https://openqa.suse.de/tests/overview?arch=ppc64le&flavor=&machine=&test=offline_install%2Bskip_registration&modules=&module_re=&version=15-SP5&distri=sle&groupid=129#" class="external">offline_install+skip_registration</a> but it runs on PowerVM backend (<code>pvm_hmc</code>) instead of QEMU.<br>
Both <code>offline_install+skip_registration_dev</code> and <code>offline_install+skip_registration</code> require an offline SUT to run. This is achieved by providing the <code>OFFLINE_SUT=1</code> setting.</p>
<p>However the <code>OFFLINE_SUT=1</code> can only set a QEMU backend offline as can be seen in <a href="https://github.com/os-autoinst/os-autoinst/blob/master/backend/qemu.pm#L825" class="external">os-autoinst/qemu.pm</a>.<br>
This ticket aims to investigate whether it is possible to set the system offline via <a href="https://github.com/os-autoinst/os-autoinst/blob/master/backend/pvm_hmc.pm" class="external">os-autoinst/pvm_hmc.pm</a> backend or even via boot parameters in the bootloader stage of the testsuite.<br>
This would hopefully prevent the failure on the PowerVM job <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=offline_install%2Bskip_registration_dev&modules=&module_re=&version=15-SP5&distri=sle&groupid=456#" class="external">offline_install+skip_registration_dev</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Investigate whether it is possible to set the PowerVM system offline via it's hypervisor settings (maybe as an <code>HMC_*</code> variable). <br>
<strong>AC2</strong>: If <strong>AC1</strong> is not possible, investigate whether it is possible to set the PowerVM system offline via a boot parameter. Some candidates here can be the <code>netdev</code> kernel parameter or the even the obsoleted <code>ether</code> parameter, which might be used to disable Ethernet cards.<br>
<strong>AC3</strong>: If any of the above works, create a new progress ticket to implement the change and move <code>offline_install+skip_registration_dev</code> from development to production, replacing the existing <code>offline_install+skip_registration</code> testsuite that runs there.</p>
qe-yam - action #118966 (Rejected): Testuiste mru-iscsi_{client,server}_normal_auth_backstore_{lv...https://progress.opensuse.org/issues/1189662022-10-17T16:13:22Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Related to <a class="issue tracker-4 status-3 priority-5 priority-high3 closed child" title="action: Add AutoYaST test suites for chained dependencies in YaST Maintenance Updates (rest of products) (Resolved)" href="https://progress.opensuse.org/issues/111743">#111743</a><br>
Testsuites <code>create_hdd_yast_maintenance_desktop</code> and <code>create_hdd_yast_maintenance_minimal</code> are performing an autoyast installation which is used by subsequent testsuites (eg <code>mau-extratests-yast2ui</code>, <code>mau_extratests_yast2_ncurses</code>, <code>mau_extratests_yast_cmd</code>).</p>
<p>However the <code>mru-iscsi</code> multimachine testsuites that have <code>create_hdd_yast_maintenance_desktop</code> as a dependency seem to bump into an issue where the Network of the resulting image is not configured, ending up with <a href="https://openqa.suse.de/tests/9742604#step/addon_products_via_SCC_yast2/25" class="external">this type of failure</a>.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p><a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=mru-iscsi_client_normal_auth_backstore_lvm_dev&test=mru-iscsi_server_normal_auth_backstore_lvm_dev&test=mru-iscsi_client_normal_auth_backstore_fileio_dev&test=mru-iscsi_server_normal_auth_backstore_fileio_dev&test=mru-iscsi_client_normal_auth_backstore_hdd_dev&test=mru-iscsi_server_normal_auth_backstore_hdd_dev&modules=&module_re=&distri=sle&build=20221016-1&groupid=446#" class="external">mru-iscsi_{client,server}_normal_auth_backstore_{lvm,fileio,hdd}</a> for MU YaST 12-SP4 to 15-SP2 Job groups.<br>
arch: x86_64</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: The mru-iscsi_{client,server}<u>normal_auth_backstore</u>{lvm,fileio,hdd} testsuites succeed on the Registration step.<br>
<strong>AC2</strong>: The mru-iscsi_{client,server}<u>normal_auth_backstore</u>{lvm,fileio,hdd} are removed from the development group, and their equivalent testsuites in the YaST MU Job Groups now have a dependency on the <code>create_hdd_yast_maintenance_desktop</code> testsuite.</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<ul>
<li>This is most probably an AutoYaST profile related issue. The <code>mru-iscsi_{client,server}_normal_auth_backstore_{lvm,fileio,hdd}</code> seem to run fine for <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP3&build=20221016-1&groupid=421" class="external">15-SP3</a> and <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP4&build=20221016-1&groupid=421" class="external">15-SP4</a>, maybe it is worth observing how network configuration is done on these autoyast installation <code>create_hdd_yast_maintenance_desktop</code> jobs.</li>
</ul>
qe-yam - action #117949 (Resolved): Apply workaround to force screen refresh on YaST Qt windowhttps://progress.opensuse.org/issues/1179492022-10-11T07:41:24Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h3 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h3>
<p>Occasionally, the screen on a YaST Qt window does not refresh properly (<a href="https://bugzilla.suse.com/show_bug.cgi?id=1204176" class="external">bsc#1204176</a>). This leads to failures like <a href="https://openqa.suse.de/tests/9681079#step/iscsi_client/52" class="external">this one</a> where content from the previous screen is still visible in the new screen, and <a href="https://openqa.suse.de/tests/9680782#step/yast2_control_center/96" class="external">this one</a> where the content does not fully load.<br>
A workaround is to hit <code>shift-F3</code> twice to bring up the style sheet selection and close it again. This forces a refresh on the YaST screen, as seen <a href="https://bugzilla.suse.com/attachment.cgi?id=862070" class="external">here</a>.<br>
We should apply this workaround to all affected areas.</p>
<a name="Scope"></a>
<h3 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h3>
<p>The workaround should be applied for 15-SP5, all archs.<br>
Concerning which areas of the code would be affected, check the <strong>Suggestion</strong> section.<br>
Workaround should be applied where is not working now, not everywhere.</p>
<a name="Acceptance-criteria"></a>
<h3 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h3>
<p><strong>AC1</strong>: Add a workaround (hitting <code>shift-f3</code> to open and close the style menu) to force a refresh on the YaST Qt window.<br>
<strong>AC2</strong>: Make sure to record a soft failure, above the workaround, mentioning the <strong>new</strong> bug <code>bsc#1204176</code> as the reason for the workaround.</p>
<a name="Suggestion"></a>
<h3 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h3>
<p>We used to apply a similar workaround where we would send <code>alt-F10</code> multiple times (actually, an <em>even number</em> of times), which would maximize and unmaximize the window, forcing a screen refresh.<br>
The workaround was removed with <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15585/files" class="external">this PR</a> when a fix was added to the new 15-SP5 builds.<br>
However this fix seems to not fully remove the refresh issue.<br>
The suggestion here is to check this PR to view in which areas of the code to introduce the <code>shift-F3</code> workaround.<br>
So for instance we could re-introduce at the same areas a <code>send_key_until_needlematch</code> but this time with <code>shift-F3</code>.</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>
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>