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 - action #80726 (New): [SLE][Migration] data migration from openldap2 -> 389-dshttps://progress.opensuse.org/issues/807262020-12-04T09:36:29Zmaritawernermawerner@suse.com
<p>Support provided evidence to Engineering (including QA) that the test coverage for LDAP (openldap2 -> 389-ds) and Active Directory (samba et al) is not sufficient to cover our customers' most important scenarios - especially in the migration scenarios from older product major versions.</p>
<p>So this is a sub ticket to track and define migration scenarios that do a real data migration from LDAP to 389-ds to not only test that the tool itself works but also that the old data are move over.<br>
More concrete scenarios need to be defind.</p>
<p>Tracker bug: <a href="https://bugzilla.suse.com/show_bug.cgi?id=1158877" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1158877</a><br>
Documentation: <a href="https://confluence.suse.com/display/documentation/389-ds+Documentation" class="external">https://confluence.suse.com/display/documentation/389-ds+Documentation</a></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 - coordination #25850 (Resolved): [sle][functional][sle15][epic] new system roleshttps://progress.opensuse.org/issues/258502017-10-09T07:39:56Zmaritawernermawerner@suse.com
<a name="situation"></a>
<h2 >situation<a href="#situation" class="wiki-anchor">¶</a></h2>
<ul>
<li><p>The role "default" will become the role "SLES + Desktop" (SLE Basesystem and Desktop Application Module available, runlevel 5, Basesystem + Gnome Desktop installed)</p></li>
<li><p>the minimal role SLES "minimal" (no registration, only packages from DVD available) will stay as is</p></li>
<li><p>there will be added a new role "SLES default" "textmode" (SLE Basesystem Module available, Basesystem + minimal X11 (icewm) installed, runlevel 3, text mode) </p></li>
</ul>
<a name="acceptance-criteria"></a>
<h2 >acceptance criteria<a href="#acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> All system roles are tested within SLE15</li>
<li><strong>AC2:</strong> SLE12/openSUSE still works - do we always have to state this? ;-)</li>
<li><strong>AC3:</strong> Existing scenarios using test variable "SYSTEM_ROLE" still work, i.e. "xen" and "kvm".</li>
</ul>
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 - coordination #15108 (Resolved): [sle][functional][u][epic] Modules (Installation +...https://progress.opensuse.org/issues/151082016-11-29T07:51:16Zmaritawernermawerner@suse.com
<p>All modules have to be installable on SLES as well. Since you get them with SCC this is an essential part of migration testing. But also installation testing makes sense.</p>
<pre><code>add a testcase for each module installed on plain SLES
add a combination of 2 or 3 modules on SLES
add testcases of an add-on and each module
</code></pre>
<p>For details about modules see<br>
<a href="https://wiki.microfocus.net/index.php/Maintenance/SLE12_SP2_Online_Migration#Add-ons_and_modules_for_SLES" class="external">https://wiki.microfocus.net/index.php/Maintenance/SLE12_SP2_Online_Migration#Add-ons_and_modules_for_SLES</a></p>
<p>See the subtickets for details</p>
openQA Tests - action #11442 (Resolved): Feature 317970: Remove creation of autoyast profile duri...https://progress.opensuse.org/issues/114422016-04-01T12:54:55Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/317970" class="external">https://fate.suse.com/317970</a></p>
<p>Feature status is "done".</p>
<p>With SLES10/SLES11, we did create an autoyast profile at the end of the installation. With both products doing a full system configuration during installation, this did made sense.</p>
<p>With SLES12, most things are no longer configureable during installation and we suggest to the customer to configure it later in the running system. So a lot of config entries are missing from this autoyast profile. And the resulting autoyast profile is different then if you create it later in the running system.</p>
<p>Thus we should stop creating the autoyast profile during installation and only concentrate on doing it later in the running system.</p>
openQA Tests - action #11440 (Resolved): Feature 317897: [BETA 1] Provide minimal possible size o...https://progress.opensuse.org/issues/114402016-04-01T12:52:10Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/317897" class="external">https://fate.suse.com/317897</a><br>
Feature status is "done".</p>
<p>The btrfs allows shrinking but to use that feature from YaST it is required to know the minimal possible size in advance. Currently this is not possible to query that size.</p>
<p>The btrfs command could provide the value for YaST.</p>
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>
openQA Tests - action #11432 (Resolved): Feature 312751: snapper: cleanup rules based on free spa...https://progress.opensuse.org/issues/114322016-04-01T12:46:57Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/312751" class="external">https://fate.suse.com/312751</a></p>
<p>First check if the Feature status is "done".</p>
<p>Description:</p>
<p>During a discussion in the Beta tester group we found that it would be useful not only cleanup btrfs snapshots based on "age", but also depending on the filesystem's fill-level and/or free space</p>
openQA Tests - action #11332 (Resolved): Install SMT pattern on SLES 12 SP1 then migrate from SP1...https://progress.opensuse.org/issues/113322016-03-29T13:55:32Zmaritawernermawerner@suse.com
<ul>
<li>Install SLES 12 SP1</li>
<li>Install SMT, see <a href="https://www.suse.com/documentation/sles-12/book_smt/data/smt_installation.html" class="external">https://www.suse.com/documentation/sles-12/book_smt/data/smt_installation.html</a></li>
<li>Migrate from SP1 to SP2 and make sure that SMT still works</li>
<li>Note: SMT pulls MySQL, might have some impacts</li>
</ul>
openQA Tests - action #11330 (Resolved): Install SMT pattern on SLES 12 SP2https://progress.opensuse.org/issues/113302016-03-29T13:52:22Zmaritawernermawerner@suse.com
<ul>
<li>Install SLES 12 SP2</li>
<li>Install SMT pattern, see <a href="https://www.suse.com/documentation/sles-12/book_smt/data/smt_installation.html" class="external">https://www.suse.com/documentation/sles-12/book_smt/data/smt_installation.html</a></li>
<li>make sure everything works fine</li>
<li>Note: SMT pulls MySQL, might have some impacts</li>
<li>Note: SMT & proxy SCC might have some impacts</li>
</ul>
openQA Tests - action #10832 (Resolved): [sle][sled]Dual-boot installation testing for SLED12 (SP2)https://progress.opensuse.org/issues/108322016-02-19T13:20:46Zmaritawernermawerner@suse.com
<p>Frederic requests to test dual-boot install on SLED12 SP2 with Windows 10 not only on BIOS but on EFI partition as well.<br>
Tumbleweed has already an openqa testcase for testing Win8/BIOS install, so it would make sense to reuse this testcase for SLED12 SP2, expand it with additionals VM (Win7, Win10) and with diferent boot environment<br>
(BIOS and UEFI) and of course, contribute back those tests to TW.</p>
openQA Tests - action #9594 (Resolved): SLERT 12 SP1 Installation testinghttps://progress.opensuse.org/issues/95942015-11-17T16:05:35Zmaritawernermawerner@suse.com
<p>Implement SLERT 12 SP1 installation tests into openQA</p>