openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-10-19T13:12:21ZopenSUSE Project Management Tool
Redmine 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 #116131 (Rejected): Ensure Boot from Hard Disk is selected in grub, migrationhttps://progress.opensuse.org/issues/1161312022-09-01T15:38:54Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p><a href="https://openqa.suse.de/tests/9427729#step/grub_test/3" class="external">Migration from 12SP5 fails</a> because the entry <code>Boot from Hard Disk</code> is not selected in grub menu of the migrated system.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>testsuite <a href="https://openqa.suse.de/tests/9427729#step/grub_test/3" class="external">sle-15-SP5-Migration-from-SLE12-SPx-x86_64-Build19.1-autoupgrade_sles12sp5_pscc_lp_def_full</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Ensure <code>Boot from Hard Disk</code> is selected in grub menu</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<p>It seems that the input that selects the entry is not registered, but also that the grub timeout is too big compared to the needle timeout. Maybe it is worth investigating if this is unexpected behavior/bug</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 #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 #108803 (Rejected): Fix key navigation in yast2 snapper ncurses testhttps://progress.opensuse.org/issues/1088032022-03-23T18:56:09Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h3 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h3>
<p>Module <code>yast2_snapper_ncurses.pm</code> fails because the snapshot is never highlighted, as can be seen here: <a href="https://openqa.suse.de/tests/8368512#step/yast2_snapper_ncurses/77" class="external">https://openqa.suse.de/tests/8368512#step/yast2_snapper_ncurses/77</a><br>
This is due to <code>send_key_until_needlematch</code>'s key <code>pgdn</code> no navigating as intended.</p>
<a name="Acceptance-criteria"></a>
<h3 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h3>
<p><strong>AC1</strong>: Manually check which key to highlight the snapshot with. If <code>pgdn</code> no longer works, investigate whether this is intended.<br>
<strong>AC2</strong>: Adjust <code>send_key_until_needlematch</code> of <code>sub y2snapper_new_snapshot</code> so that the newly created snapshot is highlighted.</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 #105978 (Rejected): Investigate kex_exchange_identification error in s390x-kvmhttps://progress.opensuse.org/issues/1059782022-02-04T17:24:22Zgeorggkioulis@suse.com
<p>Testsuites <a href="https://openqa.suse.de/tests/8104383#step/prepare_test_data/7" class="external">transactional_server_snapper</a> and <a href="https://openqa.suse.de/tests/8104382#step/prepare_test_data/6" class="external">transactional_server_helper</a> fail in <code>prepare_test_data</code> module.</p>
<p>It seems that the ssh connection of the SUT to the worker (grenache-1) is interrupted due to <code>kex_exchange_identification error</code>.</p>
<p><strong>Note:</strong> This ticket is probably not primarily for our squad, but given that it is a testsuite blocker and it would be good to see it addressed relatively quickly, I suggest that we investigate ourselves as a starting point.</p>
qe-yam - action #105975 (Rejected): Investigate disk Input/output error on ppc64le-hmchttps://progress.opensuse.org/issues/1059752022-02-04T17:05:08Zgeorggkioulis@suse.com
<p>The testsuite <a href="https://openqa.suse.de/tests/latest?arch=ppc64le&distri=sle&flavor=Online&machine=ppc64le-hmc-single-disk&test=cryptlvm%2Bcancel_existing&version=15-SP4" class="external">cryptlvm+cancel_existing</a> fails for ppc64le-hmc in <code>bootloader_start</code> module.</p>
<p>The failure appears when creating the GPT partition table on the disk.</p>
<p>The same issue appears in <a href="https://openqa.suse.de/tests/8104886" class="external">RAID5</a>, but it is only visible through the video of the job run. <br>
The job times out during <code>Performing Installation</code> due to a popup window appearing (message is: <code>Creating GPT on /dev/sdd, Unexpected situation found in the system.</code>)</p>
<p>Investigation is needed to verify whether this is a ppc64le-hmc infrastructure issue or a product bug for creating the GPT table in this specific setup.</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 #103320 (Rejected): Create new test module for DASD disk filteringhttps://progress.opensuse.org/issues/1033202021-11-30T14:13:15Zgeorggkioulis@suse.com
<a name="Description"></a>
<h2 >Description<a href="#Description" class="wiki-anchor">¶</a></h2>
<p>In DASD Disk Management page (can be seen <a href="https://openqa.suse.de/tests/7125537#step/disk_activation/2" class="external">here</a>) there is the capability of filtering DASD disks by inputting a channel range in the minimum and maximum channel ID fields.</p>
<p>We can test this by using the functionality (<code>enter_maximum_channel</code>, <code>enter_minimum_channel</code>, <code>press_filter_button</code>) provided by <code>DASDDiskManagementPage.pm</code>.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li>Create a test module that filters the shown DASD devices by a selected channel range and validate the output.</li>
<li>It is sufficient to include this test module in a single job's schedule that includes the <code>configure_dasd</code> test module, not all of them.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>An easy implementation can be to have the same channel value for minimum and maximum channel. This will make validating the output easier, since the device table item list will contain only one item to be asserted.</li>
</ul>
qe-yam - action #101903 (Rejected): Investigate test failure in integration_serviceshttps://progress.opensuse.org/issues/1019032021-11-03T15:18:29Zgeorggkioulis@suse.com
<p>The <code>integration_services.pm</code> module fails at the <code>select_console 'root-console'</code> call.<br>
This fails because the System Under Test finds itself in the display manager screen.<br>
When fixed the test behavior should be similar to <a href="https://openqa.suse.de/tests/5785744#step/integration_services/2" class="external">the old runs</a>.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Full-x86_64-select_modules_and_patterns+registration@svirt-hyperv-uefi fails in<br>
<a href="https://openqa.suse.de/tests/7591216/modules/integration_services/steps/5" class="external">integration_services</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Full Medium installation that covers the following cases:<br>
1. Additional modules enabled using SCC (Legacy, Development Tools,<br>
Web and Scripting, Containers, Desktop Applications);<br>
2. Yast patterns installed;<br>
3. System registration is skipped during installation;<br>
4. Installation is validated by successful boot and that YaST does not<br>
report any issues;<br>
5. Registration is performed on the installed system.</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/7200373" class="external">38.1</a></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=Full&machine=svirt-hyperv-uefi&test=select_modules_and_patterns%2Bregistration&version=15-SP4" class="external">latest</a></p>
qe-yam - action #99600 (Rejected): Investigate System Role page not loadinghttps://progress.opensuse.org/issues/996002021-10-01T09:43:51Zgeorggkioulis@suse.com
<p>Until now, at the end of <code>addon_products_sle</code> module, once the next button is pressed using keyboard, the System Role page appears, as can be seen in the last screen of the <code>addon_products_sle</code> module <a href="https://openqa.suse.de/tests/7200374#step/addon_products_sle/60" class="external">on previous runs</a>.</p>
<p>In the new build however, the transition to the System Role page never happens resulting in a failing needle in the <code>system_role</code> module.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Full-x86_64-select_modules_and_patterns+registration@svirt-hyperv2016 fails in<br>
<a href="https://openqa.suse.de/tests/7279621/modules/system_role/steps/2" class="external">system_role</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Full Medium installation that covers the following cases:<br>
1. Additional modules enabled using SCC (Legacy, Development Tools,<br>
Web and Scripting, Containers, Desktop Applications);<br>
2. Yast patterns installed;<br>
3. System registration is skipped during installation;<br>
4. Installation is validated by successful boot and that YaST does not<br>
report any issues;<br>
5. Registration is performed on the installed system.</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/7124547" class="external">36.1</a></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=Full&machine=svirt-hyperv2016&test=select_modules_and_patterns%2Bregistration&version=15-SP4" class="external">latest</a></p>
qe-yam - action #99573 (Rejected): Investigate failure of LVM activationhttps://progress.opensuse.org/issues/995732021-09-30T15:36:18Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-aarch64-activate_encrypted_volume+import_users@aarch64 fails in<br>
<a href="https://openqa.suse.de/tests/7274219/modules/skip_install_addons/steps/1" class="external">skip_install_addons</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/7269640" class="external">43.1</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/7217928" 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=aarch64&distri=sle&flavor=Online&machine=aarch64&test=activate_encrypted_volume%2Bimport_users&version=15-SP4" class="external">latest</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>