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>
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 #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 #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>
qe-yam - action #108758 (Closed): Wait for extensions and modules registrationhttps://progress.opensuse.org/issues/1087582022-03-22T18:25:19Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h3 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h3>
<p>On slow architectures like aarch64, Extensions and Modules Registration can take a long time, resulting in test failure.<br>
For example <a href="https://openqa.suse.de/tests/8364864#step/skip_install_addons/2" class="external">https://openqa.suse.de/tests/8364864#step/skip_install_addons/2</a></p>
<a name="Acceptance-criteria"></a>
<h3 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h3>
<p><strong>AC1</strong>: Introduce the functionality to wait for registration on <code>ModuleRegistrationController.pm</code>.<br>
<strong>AC2</strong>: Adjust <code>register_nonconflicting_modules.pm</code>, <code>register_module_transactional.pm</code> and <code>register_module_desktop.pm</code> modules as needed to wait for registration.</p>
<a name="Suggestions"></a>
<h3 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h3>
<p>Check the work that has already been done in <code>perform_installation.pm</code> with <code>PerformingInstallationController.pm</code> function <code>wait_installation_popup()</code><br>
Check for Installation Settings Page where we recently applied something like <code>is it fully loaded the page</code> method.</p>
qe-yam - action #105070 (Closed): Document Widget abbreviationshttps://progress.opensuse.org/issues/1050702022-01-19T15:12:30Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>YuiRestClient Widget entries like <code>Label</code>, <code>ProgressBar</code> and <code>Textbox</code> are abbreviated on the <code>Page</code> side (eg to <code>lbl</code>, <code>pba</code> and <code>tbx</code> for the aforementioned cases).<br>
We should document all of the agreed upon abbreviations for Widgets.</p>
<a name="Task"></a>
<h2 >Task<a href="#Task" class="wiki-anchor">¶</a></h2>
<p><strong>AC1</strong>: Have a renaming proposal and add the Widget abbreviations on the os-autoinst-distri-opensuse documentation, in <code>ui-framework-documentation.md</code> or somewhere suitable.<br>
<strong>AC2</strong>: Apply to our client in all the widgets.</p>
qe-yam - action #103718 (Closed): Select disk with YuiRestClient instead of using encrypt_lvm_sim...https://progress.opensuse.org/issues/1037182021-12-08T15:21:45Zgeorggkioulis@suse.com
<p>The page we find ourselves in <code>encrypt_lvm_simple_pwd</code> is the Select Hard Disks(s) page.<br>
The Partitioning Scheme page is not shown (there is no checkbox to enable lvm) and thus the test fails.</p>
<p>According to last GMC where this test scenario (before the iscsi bug appeared) was working we indeed need to select the disk:<br>
<a href="https://openqa.suse.de/tests/6445388#step/encrypt_lvm/2" class="external">https://openqa.suse.de/tests/6445388#step/encrypt_lvm/2</a></p>
<p>Let's apply the the test modules using libyui-rest-api which we already developed: </p>
<ul>
<li><code>tests/installation/partitioning/guided_setup/select_disks.pm</code></li>
<li><code>tests/installation/partitioning/guided_setup/encrypt_lvm_simple_pwd.pm</code></li>
</ul>
qe-yam - action #102260 (Closed): [Timebox: 16h] Investigate composition over inheritance for wid...https://progress.opensuse.org/issues/1022602021-11-11T10:38:11Zgeorggkioulis@suse.com
<p>Investigate the possibility of having different interfaces to compose common functionality between (for now) Widgets.</p>
<p>Example is the <code>is_enabled</code> function, which is re-implemented in different widget classes, but a solution of inheriting the functionality from the base class does not make sense for all widgets .</p>
<p>Suggested resources: <a href="https://en.wikipedia.org/wiki/Composition_over_inheritance" class="external">https://en.wikipedia.org/wiki/Composition_over_inheritance</a></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 #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>
openQA Tests - action #78296 (Resolved): [qe-core][qem] test fails in install_updatehttps://progress.opensuse.org/issues/782962020-11-19T13:41:03Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-12-SP3-Server-DVD-Incidents-Minimal-x86_64-qam-minimal-full@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4920287/modules/install_update/steps/48" class="external">install_update</a></p>
<p>The error message is <code>nothing provides libzypp >= 16.21.2 needed by zypper-1.13.57-21.32.1.x86_64</code></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>minimal = base pattern, minimal (enhanced base) pattern are additional convenience paclkages</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/4919728" class="external">:16986:zypper</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/4915695" class="external">:16967:ca-certificates-mozilla</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Server-DVD-Incidents-Minimal&machine=64bit&test=qam-minimal-full&version=12-SP3" class="external">latest</a></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>