openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-07-18T11:16:56ZopenSUSE Project Management Tool
Redmine openQA Infrastructure - action #113716 (Resolved): [qe-core] proxy-scc is downhttps://progress.opensuse.org/issues/1137162022-07-18T11:16:56Zmaritawernermawerner@suse.com
<p>On Friday, July 15, at 10.45 the proxy-scc stopped working. A Jira SD ticket for eng infra was raised by QE: <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-92678" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-92678</a></p>
<p>In the slack channel help-scc Jiri Novak and Thomas Schmidt from the SCC team discussed the technical details:<br>
<a href="https://suse.slack.com/archives/C02AYV7UJSD/p1657792209257829" class="external">https://suse.slack.com/archives/C02AYV7UJSD/p1657792209257829</a></p>
<p>In short: the very old caasp cluster will be replaced by a Kubernetes instance.</p>
openQA Tests - coordination #47192 (Resolved): [sle][functional][y][epic] some openQA tests in st...https://progress.opensuse.org/issues/471922019-02-06T09:23:31Zmaritawernermawerner@suse.com
<p>In the SLE Staging area <a href="https://build.suse.de/project/staging_projects/SUSE:SLE-15-SP1:GA" class="external">https://build.suse.de/project/staging_projects/SUSE:SLE-15-SP1:GA</a><br>
a lot of testcases take more than 50 Minutes.<br>
The RMs have complained that that is to long and asked us to review the Testcases and skip less important test modules, e.g. shibboleth<br>
Example: <a href="https://openqa.suse.de/tests/2436298" class="external">https://openqa.suse.de/tests/2436298</a> in Staging C</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Link to</p>
<ul>
<li><a href="https://openqa.suse.de/tests/latest?test=minimal%2Bbase&machine=64bit-staging&arch=x86_64&flavor=Installer-DVD-Staging%3AC&version=15-SP1&distri=sle" class="external">latest minimal+base</a></li>
<li><a href="https://openqa.suse.de/tests/latest?test=gnome&arch=x86_64&machine=64bit-staging&flavor=Installer-DVD-Staging%3AC&distri=sle&version=15-SP1" class="external">latest gnome</a></li>
</ul>
openQA Tests - action #43724 (Resolved): [sle][security] Bug 1110700 - remove non-enterprise ser...https://progress.opensuse.org/issues/437242018-11-13T10:37:53Zmaritawernermawerner@suse.com
<p>Is it possible to write a testcase to make sure that the Bug does not happen again?<br>
<a href="https://bugzilla.suse.com/show_bug.cgi?id=1110700" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1110700</a></p>
<p>If it is moe a bug for the Qa security team please relabel.</p>
openQA Tests - coordination #17208 (Resolved): [sle][functional][yast][y][mandatory][medium][epic...https://progress.opensuse.org/issues/172082017-02-20T08:35:06Zmaritawernermawerner@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Thin Provisioning is an imporant feature and<br>
as such it makes sense to have at least a basic test - meaning<br>
deployment of the system, which will implicitly test the subsystem itself.<br>
Yast team has fixed a bug in Yast in February about Thin Provisioned LVM<br>
installation. It showed up that there is no test coverage for this in<br>
OpenQA.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> An openQA test scenario conducting installation on thin-LVM exists and is scheduled on SLE15, openSUSE Tumbleweed and openSUSE Leap 15.0</li>
<li><strong>AC2:</strong> Also on SLE12SP4 unless there is a clear message that thin-LVM is not supported on SLE12, see <a href="https://bugzilla.suse.com/show_bug.cgi?id=1027586" class="external">bsc#1027586</a></li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ul>
<li>Understand thin provisioning, e.g. watch <a href="https://youtu.be/E4H6Ar7XIjU" class="external">https://youtu.be/E4H6Ar7XIjU</a> or read <a href="https://www.theurbanpenguin.com/thin-provisioning-lvm2/" class="external">https://www.theurbanpenguin.com/thin-provisioning-lvm2/</a></li>
<li>Test thin-LVM installation manually on TW or SLE15</li>
<li>Resurrect <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2489" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2489</a> and adapt for storage-ng</li>
<li>Get involved in <a href="https://bugzilla.suse.com/show_bug.cgi?id=1027586" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1027586</a> to find out how tho handle the pre-storage-ng situation</li>
<li>optionally keep it working for pre-storage-ng as necessary for SLE12SP4</li>
<li>Add corresponding tests for all AC1 mentioned versions, distris</li>
</ul>
openQA Tests - action #15306 (Resolved): [sles][functional]Feature 322050: Release lifecycle data...https://progress.opensuse.org/issues/153062016-12-06T07:36:28Zmaritawernermawerner@suse.com
<p>E-Mail from Libor about thet feature:</p>
<p>I'd be happy to see the test described in FATE test case field<br>
integrated in openQA for 12 SP3 and beyond. This BTW applies to all modules<br>
(Legacy, Systems Management, Cloud, ...). From my POV the integration is low<br>
priority and can be done even after 12 SP3 GA.</p>
<p>----8<---</p>
<p>I add it here with low priority, very detailed Testcase in Fate</p>
<p><a href="https://fate.suse.com/322050" class="external">https://fate.suse.com/322050</a></p>
openQA Tests - action #14774 (Resolved): [sle][functional][yast][y] Disconnected installation: gr...https://progress.opensuse.org/issues/147742016-11-14T10:21:48Zmaritawernermawerner@suse.com
<p>A SLES installation has a looooog<br>
timeout trying to grab release notes while a system is not plugged into<br>
any network at all.</p>
<p>See also <a href="https://bugzilla.suse.com/show_bug.cgi?id=1009278" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1009278</a></p>
openQA Tests - action #12910 (Resolved): Feature 320418: Proper placement of "encrypt filesystem"...https://progress.opensuse.org/issues/129102016-07-28T09:21:25Zmaritawernermawerner@suse.com
<p>Check<br>
<a href="https://fate.suse.com/320418" class="external">https://fate.suse.com/320418</a></p>
openQA Tests - action #11804 (Resolved): Feature 320678: GCC 4.8 on SDK for AArch64https://progress.opensuse.org/issues/118042016-05-04T11:41:01Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/320678" class="external">https://fate.suse.com/320678</a><br>
Feature status is "done".</p>
<p>Description:<br>
For the toolchain, we decided to do the following<br>
Build distro with GCC 4.8.<br>
ship the compiler as a package with no support for user builds (add it to SDK).<br>
As on all other architectures: Have gcc package in version 4.8 that links gcc to gcc-4.8 and have it in the SDK as well.<br>
Enable toolchain module directly during registration (see separate fate entry).<br>
Note this uses GCC 4.8 for the Kernel. If we need to switch for the kernel to a newer compiler, we can discuss later again.<br>
Following packages will be migrated from aarch64 SLES media to SDK: <br>
gcc48<br>
gcc48-c++<br>
gcc48-fortran<br>
gcc48-info<br>
gcc48-locale<br>
gcc48-objc<br>
gcc48-obj-c++<br>
libstdc++48-devel</p>
openQA Tests - action #11798 (Resolved): Feature 319981: ACPI Support for AArch64https://progress.opensuse.org/issues/117982016-05-04T11:34:07Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319981" class="external">https://fate.suse.com/319981</a></p>
<p>Feature is set to "Validation"=Done!</p>
<p>Several existing and upcoming AArch64 SoCs are enabled to boot on UEFI/ACPI. We need to consider enabling this boot path for those SoCs in addition to the existing UEFI/FDT boot.</p>
<p>Addidtionl Comments:</p>
<p>Alexander Graf (2016-05-02 11:43) [reply]<br>
The virtual machine that runs openQA today exposes both device tree and ACPI. To force Linux into ACPI mode (which gets us at least some test coverage), boot with acpi=force on the kernel command line.<br>
#14: Michal Marek (2016-05-02 16:03) [reply] <br>
Right, this will make sure that there is support for ACPI in general.. Also, it would be good to verify that without acpi=force, we are defaulting to device tree.</p>
openQA Tests - action #11794 (Resolved): Feature 319335: VNC: Secondary viewonly passwordhttps://progress.opensuse.org/issues/117942016-05-04T11:26:18Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319335" class="external">https://fate.suse.com/319335</a></p>
<p>Feature is set to "Validation"= Done!</p>
<p>Testcase:</p>
<p>First use vncpasswd tool to create passwd file.<br>
vncpasswd /tmp/file.passwd<br>
Password: <br>
Verify: <br>
Would you like to enter a view-only password (y/n)? y<br>
Password: <br>
Verify: <br>
Old version wouldn't ask you for the view-only password, new version does.<br>
Next start VNC server that uses the file for authentication. Let's start empty Xvnc with xev running inside:<br>
Xvnc :1 -SecurityTypes=VncAuth -PasswordFile=/tmp/file.passwd &<br>
DISPLAY=:1 xev<br>
Then connect to it with your favorite VNC viewer. You can do it using vncviewer:<br>
vncviewer localhost:1 -SecurityTypes=VncAuth<br>
You will be asked to enter password. If you enter the first password, you can move mouse and type in the xev window and you should see that the events are being delivered in the xev output. If you enter the view-only password, your mouse and keyboard should be ignored.</p>
openQA Tests - action #11572 (Resolved): Toolchain Module on aarch 64https://progress.opensuse.org/issues/115722016-04-12T07:03:42Zmaritawernermawerner@suse.com
<p>Make sure that the Toolchain Module is properly tested on aarch64, see Fate 320679 and 320577,</p>
openQA Tests - action #11462 (Resolved): Feature 320597 and 320699: Introduce 'zypper lifecycle' ...https://progress.opensuse.org/issues/114622016-04-01T13:08:31Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/320597" class="external">https://fate.suse.com/320597</a></p>
<p>First check if the Feature status is "done".</p>
<hr>
<p>In addition please extend the Testcase to test Feature 320699: Do not communicate End of Support dates, that change later to a previous point in time.</p>
<p>For details see <a href="https://fate.suse.com/320699" class="external">https://fate.suse.com/320699</a></p>
openQA Tests - action #11458 (Resolved): Feature 319716: Automatic Update of YaST at beginning of...https://progress.opensuse.org/issues/114582016-04-01T13:04:25Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319716" class="external">https://fate.suse.com/319716</a></p>
<p>First check if the Feature status is "done".</p>
<a name="tasks-left-to-be-done"></a>
<h2 >tasks left to be done<a href="#tasks-left-to-be-done" class="wiki-anchor">¶</a></h2>
<ul>
<li>verify on osd that it's triggered as <code>yast_no_self_update</code> on 12-sp2 server build > 2002</li>
<li>add to o3</li>
<li>optionally: extend to check that the installer really updates itself in case an update is present</li>
</ul>
openQA Tests - action #11436 (Resolved): Feature 317701: Additional bootloader testing: Do not us...https://progress.opensuse.org/issues/114362016-04-01T12:50:07Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/317701" class="external">https://fate.suse.com/317701</a></p>
<p>First check if the Feature status is "done".</p>
<p>In past perl-Bootloader is used as abstraction layer over various bootloaders and also as a way how to not write code in ycp for bootloader.<br>
Now situation is completelly different. Yast code is in ruby. We support only single bootloader. And last but not least GRUB2 configuration is just writting some values to inifile like files and run some scripts.<br>
In such situation perl-Bootloader just adds additional source of problems with no clear benefits.</p>
<p>So proposal is to write config files and run scripts directly in yast2-bootloader and keep perl-Bootloader only as thin layer for updating kernel to ensure menu is regenerated after new kernel installation.</p>
openQA Tests - action #11434 (Resolved): [sle][functional][fate#314829][fate:validation][medium] ...https://progress.opensuse.org/issues/114342016-04-01T12:48:14Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/314829" class="external">https://fate.suse.com/314829</a></p>
<a name="Situation"></a>
<h2 >Situation<a href="#Situation" class="wiki-anchor">¶</a></h2>
<p>Currently, SLES support installation with root on raid (software raid 1), however this is limited for UEFI machines, where it seems very reasonable to have also "/boot/efi" on raid 1, thus preventing issues when disk on which "/boot/efi" currently resides fails. In order to work properly, this setup also needs creation of multiple entries in UEFI (using efibootmgr), thich would point to disks of which such raid device is created.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> A manual test has been conducted for SLE 15 as well as SLE 12 SP4 showing if a system with a UEFI boot partition on RAID is bootable or not</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ul>
<li>Manually test with a current build of SLE15 (including storage-ng) if a system is bootable from a degraded RAID with /boot/efi on RAID</li>
<li>Do the same test for SLE12 SP4</li>
<li>Update the bug report in <a href="https://bugzilla.suse.com/show_bug.cgi?id=924487" class="external">bsc#924487</a></li>
<li>If possible automate the test</li>
</ul>