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>
qe-yam - action #104223 (Closed): Remove soft-fail when bug was fixedhttps://progress.opensuse.org/issues/1042232021-12-21T12:20:00Zmaritawernermawerner@suse.com
<p>In the openQA status report a number <br>
(<a href="https://openqa.io.suse.de/openqa-review/openqa_sle15_yast_status.html" class="external">https://openqa.io.suse.de/openqa-review/openqa_sle15_yast_status.html</a>)<br>
of softfails have bugs assigned that are already fixed:</p>
<ul>
<li><p>textmode@s390x-zVM-vswitch-l3<br>
<a href="https://openqa.suse.de/tests/7857197" class="external">https://openqa.suse.de/tests/7857197</a><br>
-> <a href="https://bugzilla.suse.com/show_bug.cgi?id=1142040" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1142040</a> (Ticket status: VERIFIED (FIXED), prio/severity: P3/Major, assignee: <a href="mailto:gfx-enterprise-bugs@suse.de">gfx-enterprise-bugs@suse.de</a>)</p></li>
<li><p><a href="https://openqa.suse.de/tests/7857191" class="external">https://openqa.suse.de/tests/7857191</a> -> bsc#1142146 <a href="https://bugzilla.suse.com/show_bug.cgi?id=1142146" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1142146</a> (Ticket status: RESOLVED (FIXED), prio/severity: P5/Normal, assignee: <a href="mailto:yast-internal@suse.de">yast-internal@suse.de</a>)</p></li>
<li><p>yast2_firstboot <a href="https://openqa.suse.de/tests/7857852" class="external">https://openqa.suse.de/tests/7857852</a> -> boo#1120256 <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1120256" class="external">https://bugzilla.opensuse.org/show_bug.cgi?id=1120256</a> (Ticket status: RESOLVED (WORKSFORME), prio/severity: P3/Normal, assignee: <a href="mailto:dracut-maintainers@suse.de">dracut-maintainers@suse.de</a>)</p></li>
<li><p>yast2_ncurses_gnome <a href="https://openqa.suse.de/tests/7870893" class="external">https://openqa.suse.de/tests/7870893</a> -> bsc#1083487 <a href="https://bugzilla.suse.com/show_bug.cgi?id=1083487" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1083487</a> (Ticket status: RESOLVED (FIXED), prio/severity: P2/Major, assignee: <a href="mailto:security-team@suse.de">security-team@suse.de</a>)</p></li>
</ul>
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 #47195 (Resolved): [sle][migration][functional][u][epic] check orphan...https://progress.opensuse.org/issues/471952019-02-06T09:29:11Zmaritawernermawerner@suse.com
<p>Request from Vincent M.:</p>
<p>For the context, this started with bsc#1116740 - kernel-default-base not<br>
provided in online channel, which is the most critical bugs we had in JeOS yet. <br>
Since the issue was that kernel-default-base was an orphaned package therefore<br>
JeOS users would never received any kernel updates…</p>
<p>After discussion inside the JeOS team, we came up with the decision to manually<br>
use that orphaned_packages_check.pm test to prevent such orphaned issue. </p>
<p>Now I wanted to bring this topic to QA and other PrjMgr/RM because:</p>
<ul>
<li><p>orphaned_packages_check.pm is ONLY used (AFAIK) during SLE migration test but<br>
not during regular build test. I.E checking orphaned packages from SPX when <br>
migrating to SPX+1. But no check to see if SPX+1 contains orphaned packages by <br>
himself, if this is a relevant test. Should we change that?</p></li>
<li><p>ATM orphaned_packages_check.pm require to manually check the output, is there<br>
a way to automate this somehow?</p></li>
<li><p>What about other product, do they use orphaned_packages_check.pm, something <br>
else, or nothing?</p></li>
</ul>
<p>See also: <br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/console/orphaned_packages_check.pm" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/console/orphaned_packages_check.pm</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 - 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 #34924 (Rejected): [PjM][epic][tools] Share openQA Hardware between S...https://progress.opensuse.org/issues/349242018-04-13T13:34:14Zmaritawernermawerner@suse.com
<p>I discussed that topic shortly with Santi. Good ideas but needs definitely a decision from Coolo & other openSUSe people.</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 #25812 (Rejected): [sle][functional]offline installation with ALL-Modules DVDhttps://progress.opensuse.org/issues/258122017-10-06T07:48:44Zmaritawernermawerner@suse.com
<p>For an offline installation a medium with all modules will be provided. The installer itself will not be on the medium.<br>
This medium is an ALL-Modules DVD.</p>
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 - 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 #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 - action #15546 (Resolved): [Migration] Combine both online and offline upgrades int...https://progress.opensuse.org/issues/155462016-12-19T07:45:24Zmaritawernermawerner@suse.com
<p>As we decided in the mgmt offsite we want to have all migration scenarios in 1 Jobgroup.</p>
<p>BUT:</p>
<p>Open questions:</p>
<ul>
<li>who will be in the migration subgroup and do the daily review?</li>
<li>coordinator?</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>