openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-12-15T15:56:34ZopenSUSE Project Management Tool
Redmine qe-yam - action #122059 (Resolved): Add AutoYaST testsuite for Tumbleweed on s390x z/VMhttps://progress.opensuse.org/issues/1220592022-12-15T15:56:34Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Kernel squad would like to have similar test suites <a href="https://openqa.suse.de/tests/10087068#dependencies" class="external">sequence</a> in Tumbleweed that what they use for SLE to run later on LTP tests. (more info on <a href="https://suse.slack.com/archives/C02CANHLANP/p1671098344384289" class="external">slack thread</a>)<br>
In SLE is used <a href="https://openqa.suse.de/tests/10086929" class="external">create_hdd_minimal_base</a>:</p>
<ul>
<li>Module selected: base, desktop, development, server</li>
<li>guided partitioning: no separate home</li>
<li>system role: gnome (shouldn't be better to select textmode?)</li>
<li>pattern: base and minimal</li>
<li>Major Linux security: none</li>
<li>disable grub timeout</li>
</ul>
<p>But this is s390x kvm, and in openSUSE there is only support for z/VM.<br>
Therefore Yam squad could provide similar auto-installation than for SLE but for this backend as Kernel squad needs something that run fast, because there is not booting snapshots for z/VM so any LTP test needs to run first the installation.</p>
<p>Starting point could be to convert in AutoYaST this interactive installation: <a href="https://openqa.opensuse.org/tests/2956964">https://openqa.opensuse.org/tests/2956964</a> :</p>
<ul>
<li>disk activation</li>
<li>system role: server</li>
<li>patterns: it could be more minimal comparing with the job above</li>
<li>disable grub timeout</li>
</ul>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>A new autoyast installation testsuite is to be created in <a href="openqa.opensuse.org/" class="external">openqa.opensuse.org</a>.<br>
Currently we run there a <a href="https://openqa.opensuse.org/tests/2954722" class="external">guided installation</a> which takes around 42 mins.<br>
Products: opensuse Tumbleweed<br>
Architectures: s390x with backend s390x (which just means z/VM, the only supported backend for s390x in o3 right now)</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Create auto-installation for Tumbleweed in s390x zVM<br>
<strong>AC2</strong>: File a bug if any is found for AutoYaST cloning or service order after booting to YaST<br>
<strong>AC3</strong>: Investigate and file a infrastructure bug if found<br>
<strong>AC4</strong>: if some blocker is found, consider as last option using libyui-rest-api, which is also fast (but not ideal to have interactive installation)</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>afir there was some issues with z/VM when booting but we will see what is the state. This is completely new area where to enable AutoYaST.</p>
qe-yam - action #119083 (Rejected): [Timebox: 3 days] Investigate how to make SUT offline on PowerVMhttps://progress.opensuse.org/issues/1190832022-10-19T13:12:21Zgeorggkioulis@suse.com
<p>Related to <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: Run offline_install+skip_registration with PowerVM (Resolved)" href="https://progress.opensuse.org/issues/116116">#116116</a></p>
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Testsuite <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=offline_install%2Bskip_registration_dev&modules=&module_re=&version=15-SP5&distri=sle&groupid=456#" class="external">offline_install+skip_registration_dev</a> on ppc64le in development group is similar to <a href="https://openqa.suse.de/tests/overview?arch=ppc64le&flavor=&machine=&test=offline_install%2Bskip_registration&modules=&module_re=&version=15-SP5&distri=sle&groupid=129#" class="external">offline_install+skip_registration</a> but it runs on PowerVM backend (<code>pvm_hmc</code>) instead of QEMU.<br>
Both <code>offline_install+skip_registration_dev</code> and <code>offline_install+skip_registration</code> require an offline SUT to run. This is achieved by providing the <code>OFFLINE_SUT=1</code> setting.</p>
<p>However the <code>OFFLINE_SUT=1</code> can only set a QEMU backend offline as can be seen in <a href="https://github.com/os-autoinst/os-autoinst/blob/master/backend/qemu.pm#L825" class="external">os-autoinst/qemu.pm</a>.<br>
This ticket aims to investigate whether it is possible to set the system offline via <a href="https://github.com/os-autoinst/os-autoinst/blob/master/backend/pvm_hmc.pm" class="external">os-autoinst/pvm_hmc.pm</a> backend or even via boot parameters in the bootloader stage of the testsuite.<br>
This would hopefully prevent the failure on the PowerVM job <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=offline_install%2Bskip_registration_dev&modules=&module_re=&version=15-SP5&distri=sle&groupid=456#" class="external">offline_install+skip_registration_dev</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Investigate whether it is possible to set the PowerVM system offline via it's hypervisor settings (maybe as an <code>HMC_*</code> variable). <br>
<strong>AC2</strong>: If <strong>AC1</strong> is not possible, investigate whether it is possible to set the PowerVM system offline via a boot parameter. Some candidates here can be the <code>netdev</code> kernel parameter or the even the obsoleted <code>ether</code> parameter, which might be used to disable Ethernet cards.<br>
<strong>AC3</strong>: If any of the above works, create a new progress ticket to implement the change and move <code>offline_install+skip_registration_dev</code> from development to production, replacing the existing <code>offline_install+skip_registration</code> testsuite that runs there.</p>
qe-yam - action #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 #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 #114730 (Rejected): [Timebox: 16h] Investigate which job results block approval f...https://progress.opensuse.org/issues/1147302022-07-27T12:58:27Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>When a job from our <a href="https://openqa.suse.de/group_overview/421" class="external">aggregate maintenance updates</a> fails, it blocks all the related maintenance updates from approval by the members of the <code>qam-openqa</code> group (maintenance openqa reviewers).<br>
The questions arises, what job states, other than <code>failed</code>, result in maintenance updates being blocked?<br>
Does for instance an <a href="https://openqa.suse.de/tests/9222738" class="external">incomplete</a> job or a <a href="https://openqa.suse.de/tests/9222743#" class="external">cancelled</a> job also block their related updates? <br>
Knowing this will help us better organize the required actions in the context of our Maintenance Update Review process. </p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong> Figure out what job results block update approval for qam-openqa</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<p>The maintenance openqa reviewer use this dashboard <a href="http://dashboard.qam.suse.de/blocked" class="external">http://dashboard.qam.suse.de/blocked</a> to have visibility on the blocked updates.<br>
The maintainer of this dashboard (maybe someone from qe-tools?) should be able to help.<br>
Also we could check what happen when some arch doesn't run any job.</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 #109452 (Rejected): [Timebox: 8h] Investigate script_output failure in validate_a...https://progress.opensuse.org/issues/1094522022-04-04T13:20:24Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h3 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h3>
<p>Modules <code>validate_addon_extension_repo_http</code> and <code>validate_addon_extension_repo_ftp</code> fail sporadically in <code>validate_repo_properties()</code>.<br>
The failure occurs during inside <code>script_ouput</code> stage of <code>parse_repo_data()</code> and can be seen <a href="https://openqa.suse.de/tests/8463394#step/validate_addon_extension_repo_ftp/5" class="external">here</a>, <strong>but</strong> it is most likely not related to the bsc#1193214 failure (seen <a href="https://openqa.suse.de/tests/8463394#step/validate_addon_extension_repo_http/8" class="external">here</a>).</p>
<a name="Acceptance-criteria"></a>
<h3 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h3>
<p><strong>AC1</strong>: Investigate the failure in <a href="https://github.com/os-autoinst/os-autoinst/blob/master/distribution.pm#L232" class="external">script_output</a>.<br>
<strong>AC2</strong>: File a new progress issue (or a product bug) depending on the findings.</p>
<a name="Further-Information"></a>
<h2 >Further Information<a href="#Further-Information" class="wiki-anchor">¶</a></h2>
<p>It is a bit weird that in <a href="https://openqa.suse.de/tests/8463394/logfile?filename=autoinst-log.txt" class="external">autoinst-log.txt</a> we see <code>command 'curl -f -v http://10.0.2.2:20063/k2w1yCaJzocsF6Je/current_script > /tmp/scriptC_1nj.sh' failed at /usr/lib/os-autoinst/testapi.pm line 953.</code> but the command is different in the <a href="https://openqa.suse.de/tests/8463394/#step/validate_addon_extension_repo_ftp/5" class="external">console before the failure</a></p>
qe-yam - action #106047 (Closed): Add no fatal flag to "verify_*" moduleshttps://progress.opensuse.org/issues/1060472022-02-07T09:01:15Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>A verification module's failure should not terminate a test run, which results in reduced testing coverage.</p>
<a name="Task"></a>
<h2 >Task<a href="#Task" class="wiki-anchor">¶</a></h2>
<p>Add the <code>fatal => 0</code> test flag on all modules starting with "verify_" :</p>
<pre><code>sub test_flags {
return {fatal => 0};
}
</code></pre> qe-yam - action #105440 (Resolved): Add new ZFCP devices that appear over 0.0.fc00 channelhttps://progress.opensuse.org/issues/1054402022-01-25T14:30:32Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In the <a href="https://openqa.suse.de/tests/latest?distri=sle&flavor=Online&test=zfcp&version=15-SP4" class="external">zfcp testsuite</a>, the <code>configure_zfcp_device</code> module is adding four zfcp devices based on the channel ID <code>0.0.fa00</code>.</p>
<p>Since a Host Bus Adapter (with channel ID <code>0.0.fc00</code>) is now connected to our z/VM server, in order to test against the entirety of our infrastructure, we will need to add the four new ZFCP devices that appear on the <code>0.0.fc00</code> channel.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<p><strong>AC1</strong>: Configure and add the ZFCP devices that appear on two Channel IDs: <code>0.0.fa00</code> and <code>0.0.fc00</code>. These should be 8 devices in total.<br>
<strong>AC2</strong>: Steps should be visible via screenshots or making more tests more atomic, as we pass by the sames screen twice.</p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p>Adding devices for both channels in <code>configure_zfcp_device</code> module <em>should</em> probably be enough.</p>
qe-yam - coordination #105437 (Resolved): [Epic] Refine our testing of multipathhttps://progress.opensuse.org/issues/1054372022-01-25T14:10:18Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>The FCP topology on our z/VM testing infrastructure has recently been updated.<br>
We now have two Host Bus Adapters connecting our z/VM Server to the storage.</p>
<p>You can see an overview of our updated topology <a href="https://confluence.suse.com/download/attachments/910164448/fcp_topology1_updated2.png?version=1&modificationDate=1641917169989&api=v2" class="external">here</a>.</p>
<p>Our aim is to have in place a multipath test that will check the status of the infrastructure as it currently is, and the status of multipathing on top of it.</p>
<p>For some more info about FCP and multipathing on our z/VM system check <a href="https://confluence.suse.com/display/QYT/Mainframe+Musings%3A+Playing+around+with+FCP+and+multipath#MainframeMusings:PlayingaroundwithFCPandmultipath-Faulttoleranceinaction" class="external">this confluence article</a>.</p>
qe-yam - action #103704 (Closed): [timebox:8h] Investigate failure in ibft - no /var/log/YaST2/mk...https://progress.opensuse.org/issues/1037042021-12-08T12:03:06Zgeorggkioulis@suse.com
<p>Test module <code>ibft.pm</code> seems to fail while grepping for the contents of /var/log/YaST2/mkinitrd.log, which does not exist in the system under test.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-x86_64-autoyast_iscsi_ibft@64bit fails in<br>
<a href="https://openqa.suse.de/tests/7806109/modules/ibft/steps/50" class="external">ibft</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>AutoYaST ibft installation on iSCSI disk. iSCSI configuration is validated in the installed system, as well as cloned profile is verified to check relevant sections.</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: (unknown) (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=autoyast_iscsi_ibft&version=15-SP4" class="external">latest</a></p>
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>
qe-yam - action #99570 (Rejected): Beta distribution popup appears after access_beta_distributionhttps://progress.opensuse.org/issues/995702021-09-30T15:28:09Zgeorggkioulis@suse.com
<p>The beta distribution popup delays to appear, probably due to changes introduced in the recent build.<br>
This results in the failing of the module after the <code>access_beta_distribution</code> module, <code>install_SLES</code>.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-ppc64le-RAID5@ppc64le-no-tmpfs fails in<br>
<a href="https://openqa.suse.de/tests/7277663/modules/install_SLES/steps/2" class="external">install_SLES</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>. Maintainer: slindomansilla, jrauch</p>
<p>Installation of RAID5 using expert partitioner</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/7277663" class="external">43.1</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/7218198" class="external">39.1</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=ppc64le&distri=sle&flavor=Online&machine=ppc64le-no-tmpfs&test=RAID5&version=15-SP4" class="external">latest</a></p>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>If the BETA test variable is 1, wait for the Beta Distribution popup within a corresponding duration.</p>
qe-yam - action #99567 (Rejected): aarch64 job takes more than 2h and times outhttps://progress.opensuse.org/issues/995672021-09-30T14:06:05Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h1 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h1>
<p>The <a href="https://openqa.suse.de/tests/7275652" class="external">aarch64 select_modules_and_patterns+registration</a> job seems to now take occasionally more than two hours to complete.</p>
<p>A suggested point of action would be to make MAX_JOB_TIME more than the current 7200 seconds for this specific testsuite.</p>