openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-01-20T15:09:49ZopenSUSE Project Management Tool
Redmine 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>
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 #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>
qe-yam - action #116365 (Resolved): Add AutoYaST test suites for chained dependencies in YaST Mai...https://progress.opensuse.org/issues/1163652022-09-08T15:43:25Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>See <a class="issue tracker-6 status-3 priority-4 priority-default closed parent" title="coordination: [Epic] Add AutoYaST test suites for dependencies in YaST Maintenance Updates and keep interactive... (Resolved)" href="https://progress.opensuse.org/issues/109187">#109187</a><br>
It is done for SLE-15-SP{3,4} in <a class="issue tracker-4 status-5 priority-5 priority-high3 closed child" title="action: Add AutoYaST test suites for dependencies in YaST Maintenance Updates and keep interactive instal... (Closed)" href="https://progress.opensuse.org/issues/109214">#109214</a>. Let's try to reuse the same AutoYaST profile for the rest of the products in maintenance.<br>
<a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=mru-install-desktop-with-addons&modules=&module_re=&distri=sle&version=12-SP4&version=12-SP5&build=20220907-1&groupid=414#" class="external">mru-install-desktop-with-addons</a> | <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=mru-install-minimal-with-addons&modules=&module_re=&distri=sle&version=12-SP4&version=12-SP5&build=20220907-1&groupid=414#" class="external">mru-install-minimal-with-addons</a></p>
<p>These new testsuites should be put in YaST Development job group. Then we will file another ticket to deploy this in YaST MU job group.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>Test suites with external dependencies: <code>mru-install-desktop-with-addons</code> & <code>mru-install-minimal-with-addons</code><br>
Products: SLE 12-SP4 and SLE 12-SP5.<br>
Architectures: <code>mru-install-minimal-with-addons</code> is running in three architectures, aim for all of them if possible.</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: New AutoYaST test suites are created in 'YaST Maintenance Updates - Development' openQA job group corresponding to <code>mru-install-desktop-with-addons</code> & <code>mru-install-minimal-with-addons</code>.<br>
<strong>AC2</strong>: Copies of the chained dependencies of test suites <code>mru-install-desktop-with-addons</code> & <code>mru-install-minimal-with-addons</code> which are in YaST MU job group will be set to new AutoYaST test suites in 'YaST Maintenance Updates - Development' job group<br>
<strong>AC3</strong>: If we cannot reuse the AutoYaST profile created for SLE-15-SP{3,4} consider to reduce the scope of products or architectures to migrate to AutoYaST.</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<ul>
<li>Reuse knowledge from previous task: <a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="action: Migrate create_hdd_gnome in Functional group to use AutoYaST (Closed)" href="https://progress.opensuse.org/issues/107674">#107674</a> <a class="issue tracker-6 status-3 priority-4 priority-default closed parent" title="coordination: [Epic] Add AutoYaST test suites for dependencies in YaST Maintenance Updates and keep interactive... (Resolved)" href="https://progress.opensuse.org/issues/109187">#109187</a></li>
<li>We could reuse very likely the AutoYaST profiles created for SLE-15-SP3.</li>
<li>Rename the teststuites creating AutoYaST image to <code>autoyast_create_*</code> so we can distinguish better between old and new things regardless of the job group, maintenance or product.</li>
</ul>
<p>For sle-12-sp5 seems that we can reuse the profile, but for sle-12-sp4 where we have some issue with ltss we need to figure out.</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 #115619 (Resolved): Adjust send_key_until_needlematch `$counter` argument in test...https://progress.opensuse.org/issues/1156192022-08-22T15:15:21Zgeorggkioulis@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 addressed in <a href="https://progress.opensuse.org/issues/107749" class="external">poo#107749</a> with <a href="https://github.com/os-autoinst/os-autoinst/pull/2151" class="external">this PR</a>.<br>
It is now needed to adjust all testsuites that make use of <code>send_key_until_needlematch</code> by increasing the <code>$counter</code> argument by one, if this argument is used.</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>AC1</strong>: Make sure that all testsuites that call <code>send_key_until_needlematch</code> and pass the <code>$counter</code> argument as n, now pass n+1.</p>
<a name="Suggestion"></a>
<h3 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h3>
<p>Since the scope is so vast, it would be hard to do extensive verification runs. One recommendation is to do a small sample of verification runs.</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 #111458 (Resolved): Create a small cli/script to help debugging failures with mai...https://progress.opensuse.org/issues/1114582022-05-23T12:09:16Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>We now have responsibility of YaST tests in <a href="https://openqa.suse.de/group_overview/421" class="external">YaST Maintenance Updates</a>.<br>
This means that we will have to debug failures that could be caused by maintenance updates installed on the systems of those runs. <br>
In order to facilitate with this it would be convenient to have a tool that shows a small overview of the maintenance updates that are applied to a job.</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Given an openQA job id, the script can retrieve incidents IDs filtering by product module.<br>
<strong>AC2</strong>: The script can query information for those IDs that helps to debugs problems (for instance patchinfo)<br>
<strong>AC3</strong>: The script should be simple enough, containing a few lines that are easy to maintain.<br>
<strong>AC4</strong>: Consider how we could filter YaST related updates with the final output (not implementation required).</p>
<a name="Suggestion"></a>
<h4 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h4>
<ul>
<li><p>Using the <code>openQA Job ID</code> we should be able to construct the var.json url of the job (eg <code>https://openqa.suse.de/tests/8805896/file/vars.json</code>). We can either parse the .json file to get get the Incident IDs from <code>.*_TEST_ISSUES</code> or from the <code>MAINT_TEST_REPO</code> variables.</p></li>
<li><p>Script should be able to give us incident ids related to specific products, for example if we are only interested in <code>HPCM_TEST_ISSUES</code> we could filter by HPCM, but also we could also interested on ASMM, so we could specify a comma-separated list <code>HPCM,ASMM</code>. Without filter we should get all of them present in the vars.json.</p></li>
<li><p>For each Incident ID we should be able to get the <code>patchinfo</code> of the update. Eg for Incident ID <code>24365</code> this can be done either via getting the file <a href="https://build.suse.de/source/SUSE:Maintenance:24364/patchinfo/_patchinfo">https://build.suse.de/source/SUSE:Maintenance:24364/patchinfo/_patchinfo</a> , or by scraping <a href="https://build.suse.de/package/view_file/SUSE:Maintenance:24365/patchinfo/_patchinfo?expand=1">https://build.suse.de/package/view_file/SUSE:Maintenance:24365/patchinfo/_patchinfo?expand=1</a> , or via osc commands. All three methods require a login first.</p></li>
<li><p>The tool should output a small amount of information for each Incident ID. The patchinfo file may contain more info than needed so it could need additional parsing.</p></li>
<li><p>Once we have a script easy to maintain for us if we would see that we need more features, we will be in a better position to know what we want exactly and we can consider other existing and more powerful tools in that case, but likely this would be enough for our goal.</p></li>
<li><p>Perhaps just grep by "yast" is enough but perhaps there are more YaST components or maintained by YaST developers which do not start by "yast". We could figure out or ask them, but we don't need to implement that additional filtering for now.</p></li>
</ul>
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>