openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842020-12-04T09:36:29ZopenSUSE Project Management Tool
Redmine 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 - action #34411 (Resolved): [sle][migration] Bsc#1086818 Migration: new modules not ...https://progress.opensuse.org/issues/344112018-04-06T13:20:40Zmaritawernermawerner@suse.com
<p>bsc#1086818 Migration: new modules not correctly added <br>
is a shipstopper that is not covered in our testcases yet. Once fixed we need to test it.</p>
<p>Testing instructions from Thorsten Kukuk:</p>
<blockquote>
<p>Could you please provide us a few Testcases that can be performed to make<br>
sure that migration works and the bug is fixed?</p>
</blockquote>
<p>The test case is the initial comment from me. You need to make sure, that<br>
all added Modules are installed and registered.</p>
<blockquote>
<p>Is it a valid Testcase to test with SUSEConnect the list of available<br>
Modules and check if all expected modules are correctly registered? And what<br>
is the correct list of expected modules for what scenario?</p>
</blockquote>
<p>The list of expected modules is a moving target, hard coding <br>
anything doesn't help here.<br>
As I did show you: you need to show which Modules are there,<br>
if the -release.rpm from this Module is installed and if this<br>
Module is registered.<br>
See bsc#1086846 *-release.rpm not installed for modules added via add_on_products.xml</p>
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 - action #25722 (Resolved): [migration] a simple installation with SMThttps://progress.opensuse.org/issues/257222017-10-02T13:05:14Zmaritawernermawerner@suse.com
<p>Installations are tested with SCC/proxySCC. To make sure that SMT also works fine we have to do 1 simple installation with an SMT.</p>
openQA Tests - action #17042 (Resolved): [sles][functional][modules] Modules installationhttps://progress.opensuse.org/issues/170422017-02-14T08:16:58Zmaritawernermawerner@suse.com
<a name="goal"></a>
<h2 >goal<a href="#goal" class="wiki-anchor">¶</a></h2>
<p>Make sure that each module installs correctly.</p>
<a name="acceptance-criteria"></a>
<h2 >acceptance criteria<a href="#acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: One module is tested on every SLES build using proxy-SCC</li>
<li><strong>AC2</strong>: Multiple modules are tested</li>
</ul>
<a name="tasks"></a>
<h2 >tasks<a href="#tasks" class="wiki-anchor">¶</a></h2>
<ul>
<li>set <code>SCC_ADDONS=<module_name1>[,<module_name2>]</code> accordingly (SCC regurl should only register SLES, not point to any module)</li>
<li>after the module(s) are registered and enabled packages should be installed from the modules, e.g. by selecting the appropriate pattern(s)</li>
</ul>
<a name="further-details"></a>
<h2 >further details<a href="#further-details" class="wiki-anchor">¶</a></h2>
<p>As SLE service packs and therefore also builds within service packs are meant to be ABI compatible modules can be simply installed over SCC while registering the latest SLES build. For all modules that are already on SCC we just install them over SCC (That's it. No need to sync anything anywhere).<br>
Enabling modules does not install anything from it automatically. patterns or packages need to be selected, e.g. after enabling "hpcm" then "zypper search hpc" should return something. Also the repository can be explicitly selected with "zypper lr" and then all packages and patterns from that repo can be listed with "zypper search -r ".<br>
So far module installation was never done besides textmode during online migration but these are actually "post-validation" tests as described in #15800.</p>
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 #14718 (Resolved): [Migration] [SP3]add offline migration scenarios SP2->SP...https://progress.opensuse.org/issues/147182016-11-09T14:59:09Zmaritawernermawerner@suse.com
<p>With SP3 we need to add the offline migration scenarios from SP2 to SP3.</p>
<p>As long as we do not have a PRD or other requirements we copy the SP1->SP2 scenarios and adjust them.</p>
<p>ATM we only have x86_64 and ppc64le upgrade scenarios.</p>
openQA Tests - action #12908 (Resolved): Feature 318875 and 320919: Add Saltstack to the Advanced...https://progress.opensuse.org/issues/129082016-07-28T09:18:49Zmaritawernermawerner@suse.com
<p>Check<br>
<a href="https://fate.suse.com/318875" class="external">https://fate.suse.com/318875</a><br>
<a href="https://fate.suse.com/320919" class="external">https://fate.suse.com/320919</a></p>
openQA Tests - action #11454 (Resolved): Feature 319624: YaST - Existing SSH Host Keys Dialoghttps://progress.opensuse.org/issues/114542016-04-01T13:02:05Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319624" class="external">https://fate.suse.com/319624</a></p>
<p>First check if the Feature status is "done".</p>
<p>YaST has the following feature that could lead to security implications.</p>
<a name="httpswwwsusecomdocumentationsles-12book_sle_deploymentdatasec_i_yast2_proposalhtml"></a>
<h2 ><a href="https://www.suse.com/documentation/sles-12/book_sle_deployment/data/sec_i_yast2_proposal.html" class="external">https://www.suse.com/documentation/sles-12/book_sle_deployment/data/sec_i_yast2_proposal.html</a><a href="#httpswwwsusecomdocumentationsles-12book_sle_deploymentdatasec_i_yast2_proposalhtml" class="wiki-anchor">¶</a></h2>
<p>HINT: Existing SSH Host Keys</p>
<a name="If-you-install-SUSE-Linux-Enterprise-Server-on-a-machine-with-one-or-more-existing-Linux-installations-the-installation-routine-automatically-imports-the-SSH-host-key-with-the-most-recent-access-time-from-an-existing-installation"></a>
<h2 >If you install SUSE Linux Enterprise Server on a machine with one or more existing Linux installations, the installation routine automatically imports the SSH host key with the most recent access time from an existing installation.<a href="#If-you-install-SUSE-Linux-Enterprise-Server-on-a-machine-with-one-or-more-existing-Linux-installations-the-installation-routine-automatically-imports-the-SSH-host-key-with-the-most-recent-access-time-from-an-existing-installation" class="wiki-anchor">¶</a></h2>
<p>If a system was compromised the keys shouldn't be used during system re-installation. Currently the user needs to delete the keys manually or to delete the complete partition table so that YaST will not find the data during installation.</p>
<p>The idea of this feature is to have a special YaST dialog that notifies the user that an old system was found and offers the option to import the existing SSH keys. This would make the import and the already existing feature more transparent.</p>
<p>The current list is here, in control file: <a href="https://github.com/yast/skelcd-control-SLES/blob/d2f9a79c0681806bf02eb38c4b7c287b9d9434eb/control/control.SLES.xml#L53-L71" class="external">https://github.com/yast/skelcd-control-SLES/blob/d2f9a79c0681806bf02eb38c4b7c287b9d9434eb/control/control.SLES.xml#L53-L71</a> </p>
openQA Tests - action #11450 (Resolved): Feature 318787: YaST logic on Network Restart while no c...https://progress.opensuse.org/issues/114502016-04-01T12:59:32Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/318787" class="external">https://fate.suse.com/318787</a></p>
<p>First check if the Feature status is "done". Feature is marked as "done".</p>
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>