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 #115622 (Resolved): Install kdumptool where needed and fix synchronization failur...https://progress.opensuse.org/issues/1156222022-08-22T15:42:21Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Kdump is not a dependency of yast2-kdump module in SLE15-SP5 and is no longer installed when yast2-kdump is installed.<br>
This behavior is intended as can be seen in <a href="https://bugzilla.suse.com/show_bug.cgi?id=1202535" class="external">bsc#1202535</a> and is a feature, not a bug.<br>
However this may be the cause of failures on our yast2_kdump testsuite, which need to be investigated (they are differ by architecture).</p>
<ul>
<li>aarch64 and x86_64: both fail because kdumptool is not available, which makes sense since kdump has not been installed. Even when installing kdump however, the testsuites fail because no crashkernel arguments have been added in grub config.</li>
<li>ppc64le : test does not catch the expected restart popup</li>
<li>s390x : code execution finished too early</li>
</ul>
<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=&modules=yast2_kdump&module_re=&distri=sle&version=15-SP5&build=15.2&groupid=129#" class="external">https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=&modules=yast2_kdump&module_re=&distri=sle&version=15-SP5&build=15.2&groupid=129#</a> <br>
<code>ppc64le-spvm</code> is hit by a libyui bug (bsc#1202575) but the rest architectures failures are within scope. </p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Setup properly the kdump installing only for SLE-15-SP5 necessary tools and fix sync issues with reboot screen.<br>
<strong>AC2</strong>: File found bugs if any.</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<p>When fixing sync issues, please take a look to Kernel squad where this module is used for real, doing a real kdump, not just configuring it.<br>
Perhaps we need to install development module, this test suite is still linked to Functional job group to an interactive installation, we should aim to have a textmode installation with development module included in the future.</p>
qe-yam - action #114682 (Resolved): Fix HDD name matching in mru-iscsi maintance update jobshttps://progress.opensuse.org/issues/1146822022-07-26T10:19:29Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>In YaST Maintenance updates there have been recent failures in the <code>mru-iscsi</code> server and client jobs such as <a href="https://openqa.suse.de/tests/9214130" class="external">this one</a>.<br>
The failure is that the qcow stated in the HDD_1 setting does not exist.<br>
The jobs have dependency on <code>create_hdd_yast_maintenance_desktop</code> which generate a qcow without issue.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>Testsuites: mru-iscsi_client_normal_auth_backstore_fileio, mru-iscsi_server_normal_auth_backstore_fileio, mru-iscsi_client_normal_auth_backstore_hdd, mru-iscsi_server_normal_auth_backstore_hdd, mru-iscsi_client_normal_auth_backstore_lvm, mru-iscsi_server_normal_auth_backstore_lvm<br>
Products: 15-SP3, 15-SP4</p>
<a name="Acceptance-Criteria"></a>
<h4 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Make sure that PUBLISH_HDD from <code>create_hdd_yast_maintenance_desktop</code> and HDD_1 from the <code>iscsi</code> jobs have the same form.<br>
<strong>AC2</strong>: Provide verification runs for the fix.</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<p>Delete the -%FLAVOR%-%MACHINE% from the HDD_1 parameters of the <code>iscsi</code> jobs so that the expected qcow name matches the one generated from <code>create_hdd_yast_maintenance_desktop</code></p>
<a name="Further-Information"></a>
<h4 >Further Information<a href="#Further-Information" class="wiki-anchor">¶</a></h4>
<p>Related merge request: <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/merge_requests/328" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml/-/merge_requests/328</a></p>
qe-yam - action #107749 (Resolved): Send the correct number of keys in send_key_until_needlematchhttps://progress.opensuse.org/issues/1077492022-03-01T13:48:28Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h3 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h3>
<p>Function <code>send_key_until_needlematch</code>, instead of sending the specified key <code>n</code> times, passed via argument, sends the key <code>n+1</code> times before failing.<br>
This is an issue for some scenarios, for example if an even number of keypresses is required, as is the case of maximizing and unmaximizing a window, by sending an even number of <code>alt-f10</code>.</p>
<a name="Scope"></a>
<h3 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h3>
<p>Affects all testsuites that call testapi's <code>send_key_until_needlematch</code>.</p>
<a name="Acceptance-criteria"></a>
<h3 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h3>
<p><strong>ΑC1</strong>: Modify <code>send_key_until_needlematch</code> so that key is sent the exact amount of times specified in the argument, before failing.<br>
<strong>AC2</strong>: Make sure that testsuites that use <code>send_key_until_needlematch</code> are not affected</p>
<a name="Suggestion"></a>
<h3 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h3>
<p>Change the <code>send_key_until_needlematch</code> so that <code>if (!$counter--)</code> becomes <code>if (!--$counter)</code> so that the <code>assert_screen</code> command is executed when <code>$counter</code> has become 0, not -1.</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 #99180 (Resolved): test fails in scc_registration in QR 15-SP3https://progress.opensuse.org/issues/991802021-09-24T10:49:22Zgeorggkioulis@suse.com
<p>After a recent change where the multipath activation pop up appears right after disk activation has been completed, the multipath module needs to precede the registration module in the zfcp jobs.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP3-Online-QR-s390x-zfcp@s390x-zfcp fails in<br>
<a href="https://openqa.suse.de/tests/7215665/modules/scc_registration/steps/5" class="external">scc_registration</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: 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/7141435" class="external">188.16</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/6872082" class="external">188.15</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=s390x&distri=sle&flavor=Online-QR&machine=s390x-zfcp&test=zfcp&version=15-SP3" class="external">latest</a></p>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>Alter the order the schedule so that multipath module precedes the registration.</p>
openQA Tests - action #96986 (Workable): [qe-core][sporadic][samba_adcli] net ads join / leave failshttps://progress.opensuse.org/issues/969862021-08-16T13:36:01Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p><code>net ads join</code> occasionally fails in <a href="https://openqa.suse.de/tests/6838830#step/samba_adcli/55" class="external">samba_adcli</a></p>
<p>The command <code>net ads join --domain geeko.com -U Administrator --no-dns-updates -i</code> occasionally fails with:</p>
<pre><code>ads_print_error: AD LDAP ERROR: 53 (Server is unwilling to perform): 0000001F: SvcErr: DSID-031A1236, problem 5003 (WILL_NOT_PERFORM), data 0
</code></pre>
<p>similar issue for the command <code>net ads leave --domain geeko.com -U Administrator -i'</code></p>
<p>For now it has been softfailed.</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/6839956#step/samba_adcli/60" class="external">ge0r/os-autoinst-distri-opensuse#retry-adcli-join</a> (or more recent)</p>
openQA Tests - action #96983 (Workable): [qe-core][sporadic][samba_adcli] adcli joining domain failshttps://progress.opensuse.org/issues/969832021-08-16T13:24:46Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>adcli join fails in <a href="https://openqa.suse.de/tests/6840326/modules/samba_adcli/steps/220" class="external">samba_adcli</a></p>
<p>The command <code>adcli join -v -W --domain geeko.com -U Administrator -C</code> sporadically results in :</p>
<pre><code>Couldn't perform discovery search: Can't contact LDAP server
* Received NetLogon info from: WIN-NHOU56DRDK4.geeko.com
! Cannot set computer password: Authentication error
adcli: joining domain geeko.com failed: Cannot set computer password: Authentication error
</code></pre>
<p>Increasing the number of retries just reduces the frequency of the failure. For now it has been softfailed.</p>
<p>The expected output of the aforementioned <code>adcli join</code> command can be seen <a href="https://openqa.suse.de/tests/6839956#step/samba_adcli/226" class="external">here</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/6840326" class="external">ge0r/os-autoinst-distri-opensuse#retry-adcli-join</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/6839956" class="external">ge0r/os-autoinst-distri-opensuse#retry-adcli-join</a> (or more recent)</p>
openQA Tests - coordination #96980 (Workable): [qe-core][samba_adcli][epic] Tracker for samba_adc...https://progress.opensuse.org/issues/969802021-08-16T13:23:29Zgeorggkioulis@suse.comopenQA Tests - action #96513 (Workable): [qe-core][sporadic][samba_adcli] wbinfo failshttps://progress.opensuse.org/issues/965132021-08-03T12:18:07Zgeorggkioulis@suse.com
<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-aarch64-mau-extratests2@aarch64-virtio fails in<br>
<a href="https://openqa.suse.de/tests/6630974/modules/samba_adcli/steps/78" class="external">samba_adcli</a></p>
<p>Test samba_adcli sporadicly fails due to wbinfo failures<br>
eg <code>wbinfo -u</code> fails with <code>Error looking up domain users</code></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>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/6630974" class="external">20210802-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/6628144" class="external">20210801-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=mau-extratests2&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #95611 (Workable): [qe-core][samba_adcli] test fails in samba_adcli in s390...https://progress.opensuse.org/issues/956112021-07-19T08:30:46Zgeorggkioulis@suse.com
<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-s390x-Build20210719-1-mau-extratests2@s390x-kvm-sle12 fails in <a href="https://openqa.suse.de/tests/6483346#step/samba_adcli/60" class="external">samba_adcli</a></p>
<p>From what I understand, the samba_adcli module has never been run for s390. </p>
<p>The <code>adcli join -v -W --domain geeko.com -U Administrator -C</code> does not work, even with multiple retries, possibly is a network access problem on one of the lpars</p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ol>
<li>Run a manual installation or use an image on an s390 kvm machine and/or lpar (zkvm), and try to run the steps manually</li>
<li>If step above works, trigger a job in openQA and use developer mode (Trigger the job with PAUSE_AT=samba_adcli and use <a href="https://confluence.suse.com/pages/viewpage.action?pageId=742719853" class="external">this page</a> to figure out how to connect to the running machine, possibly for s390 zkvm the procedure might be different, ping szarate) and debug the network (starting with trying to ssh Administrator@$AD_ip/windows machine).</li>
<li>Update test module/and/or modify host, create follow up tickets as needed</li>
</ol>
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 #72037 (Workable): [yast][security][qem][shim] Enable shim testing on barem...https://progress.opensuse.org/issues/720372020-09-28T16:37:18Zgeorggkioulis@suse.com
<p>Although we do have openQA runs with secure boot, there is need for <code>shim</code> testing on baremetal machine with secure boot.</p>
<p>probably the following would need to be scheduled:</p>
<ul>
<li>security/mokutil_sign.pm</li>
<li>console/verify_efi_mok.pm</li>
</ul>