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 - action #13750 (Resolved): HPC Module https://progress.opensuse.org/issues/137502016-09-16T07:28:15Zmaritawernermawerner@suse.com
<p>For details see HPC Tracker feature</p>
<p><a href="https://fate.suse.com/320596" class="external">https://fate.suse.com/320596</a></p>
<ul>
<li>Install the HPC module</li>
<li>Look into the features listed in the tracker feature</li>
<li>Check with Egbert Eich: more details needed, no Testcases available</li>
</ul>
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 #11800 (Resolved): Feature 320292: ALPN support for opensslhttps://progress.opensuse.org/issues/118002016-05-04T11:35:26Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/320292" class="external">https://fate.suse.com/320292</a></p>
<p>Feature is set to done.</p>
<p>Testcase:</p>
<p>setup apache2 host with ALPN support, (basically configure SSL and also follow<br>
<a href="https://httpd.apache.org/docs/trunk/mod/mod_http2.html" class="external">https://httpd.apache.org/docs/trunk/mod/mod_http2.html</a> adding "Protocols h2 http/1.1"<br>
to test the setup, from opensuse factory: curl --http2 <a href="https://HOSTNAME" class="external">https://HOSTNAME</a><br>
The call also might need the --insecure option too if you used a self-signed certificate during apache2 setup.<br>
Another simpler test can be: server# openssl s_server -key key.pem -cert cert.pem -alpn http<br>
client# openssl s_client -connect server:4433 -alpn http<br>
And check the client output for "ALPN protocol: http" / "No ALPN negotiated"</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 #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 #11564 (Resolved): s390x: add SSH+GUI as frontend to the Installation processhttps://progress.opensuse.org/issues/115642016-04-11T08:27:44Zmaritawernermawerner@suse.com
<p>as discussed with Matthias</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 #11460 (Resolved): Feature 320494: Disable installation source after instal...https://progress.opensuse.org/issues/114602016-04-01T13:06:12Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/320494" class="external">https://fate.suse.com/320494</a></p>
<p>First check if the Feature status is "done".</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 #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 #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>