openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-03-21T09:51:42ZopenSUSE Project Management Tool
Redmine openQA Tests - action #157657 (Feedback): PackageHub module activation while using SCC-proxyhttps://progress.opensuse.org/issues/1576572024-03-21T09:51:42Zjlausuchjalausuch@suse.com
<a name="Problem-statement"></a>
<h2 >Problem statement:<a href="#Problem-statement" class="wiki-anchor">¶</a></h2>
<p>When registering the system using ProxySCC, activating the PackageHub module returns repos in OSD that don't exist.<br>
This is expected, because the proxySCC replaces the repo URLs given by the real SCC by local openQA asset URL.</p>
<p>Normally, we use the proxySCC in the openQA jobs with <code>SCC_URL</code> variable, this will be used by the code to make the <code>SUSEConnect</code> call like this:</p>
<p><code>SUSEConnect -r $REGCODE --url http://all-67.1.proxy.scc.suse.de</code></p>
<p>This will make that all the repos returned look like this:<br>
<code>http://openqa.suse.de/assets/repo/...</code></p>
<p>And enabling any module, will have the same effect, for example PackageHub:</p>
<pre><code>
susetest:~ # suseconnect -p PackageHub/15.6/x86_64
Registering system to registration proxy http://all-67.1.proxy.scc.suse.de
Updating system details on http://all-67.1.proxy.scc.suse.de ...
Activating PackageHub 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Successfully registered system
</code></pre>
<p>And the repo will point to the wrong place:</p>
<pre><code>18 | SUSE_Package_Hub_15_SP6_x86_64:SLE-Module-Packagehub-Subpackages15-SP6-Pool | SLE-Module-Packagehub-Subpackages15-SP6-Pool | Yes | (r ) Yes | No | http://openqa.suse.de/assets/repo/SLE-15-SP6-Module-Packagehub-Subpackages-POOL-x86_64-Build67.1-Media1/
</code></pre>
<a name="Solution"></a>
<h2 >Solution<a href="#Solution" class="wiki-anchor">¶</a></h2>
<p>To cope with this, we would need to sync the PackageHub module for EVERY build we have for 15-SP6. Another solution would be to tweak ProxySCC code to return the real URL instead of local assets.</p>
<p>BUT there is an easier way:<br>
1) Register the system using the usual proxySCC</p>
<pre><code>susetest:~ # SUSEConnect -r $REGCODE --url http://all-67.1.proxy.scc.suse.de
Registering system to registration proxy http://all-67.1.proxy.scc.suse.de
Announcing system to http://all-67.1.proxy.scc.suse.de ...
Activating SLES 15.6 x86_64 ...
-> Adding service to system ...
Activating sle-module-basesystem 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Activating sle-module-server-applications 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Activating sle-module-python3 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Successfully registered system
</code></pre>
<p>2) Activate the desired module using <code>--url</code> pointing to real SCC:</p>
<pre><code>susetest:~ # SUSEConnect -p PackageHub/15.6/x86_64 --url https://scc.suse.com
Registering system to SUSE Customer Center
Updating system details on https://scc.suse.com ...
Activating PackageHub 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Successfully registered system
</code></pre>
<p>3) And voilá, you will get the repos from REAL SCC:</p>
<pre><code>susetest:~ # zypper lr -u |grep -i PackageHub-15-SP6-Pool
22 | SUSE_Package_Hub_15_SP6_x86_64:SUSE-PackageHub-15-SP6-Pool | SUSE-PackageHub-15-SP6-Pool | Yes | (r ) Yes | No | https://updates.suse.com/SUSE/Backports/SLE-15-SP6_x86_64/product?RMMzfgZAuv8Hy903n30FsW6hbWs5KExVGGIwF1w5nRMdkliFvRBscHmgomWpHwFbG8l2C7cmrcZead-ejTo_f0NKbts7ZNwGBw0WtMwuWeKXxK2mgknqmbcYZ22y3RB3rThU1AMZTw
</code></pre> ALP - action #153760 (Resolved): [qe-core]Adapt svirt backend to be able to boot systems with roo...https://progress.opensuse.org/issues/1537602024-01-17T08:59:42Zjlausuchjalausuch@suse.com
<p>ALP images (following Factory approach) do not allow root ssh by default, the best practices are to use a key-pair to ssh to the system.</p>
<p>There is a way to enable it, which consists of installing the package <code>openssh-server-config-rootlogin</code>, which is simply doing <code>echo 'PermitRootLogin yes' >> /etc/sshd/sshd_config.d/root_login_config.</code>.</p>
<p>Our svirt backend rely on doing a root ssh to the machine after it's booted, therefore it fails to do so.</p>
<p>There are several ideas to workaround this:<br>
1) Add <code>echo 'PermitRootLogin yes' >> /etc/sshd/sshd_config.d/root_login_config >$pty</code> to the svirt backend commands. <br>
2) Create a keypair for each run and inject it to the VM using svirt backend commands. <br>
3) Create new combustion script for s390x including the command `echo 'PermitRootLogin yes' >> /etc/sshd/sshd_config.d/root_login_config</p>
<a name="Acceptance-criteria"></a>
<h3 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h3>
<ul>
<li>ALP s390x images boot with svirt backend</li>
</ul>
openQA Tests - action #151738 (Feedback): [qe-core] Enable systemd-testsuite in 15-SP6https://progress.opensuse.org/issues/1517382023-11-30T09:41:09Zjlausuchjalausuch@suse.com
<a name="Background"></a>
<h2 >Background<a href="#Background" class="wiki-anchor">¶</a></h2>
<p>There is an important update for systemd in 15-SP6 to v254: <a href="https://jira.suse.com/browse/PED-4846" class="external">https://jira.suse.com/browse/PED-4846</a><br>
Some important partners are a bit worried about this update and have asked us to please make sure this doesn't break any application (e.g. SAP applications).<br>
We can't ensure 3rd party applications will be ok with this update, but what we can do is to provide good coverage for systemd testing (of course, SAP part will be covered by SAP squad). </p>
<p><code>systemd-testsuite</code> has been integrated in openQA and enabled in TW by Martin Loviska when he was on rotation. e.g. <a href="https://openqa.opensuse.org/tests/3760221" class="external">https://openqa.opensuse.org/tests/3760221</a><br>
It was also enabled in 15-SP4 and SP5 after GA, but the package is already in 15-SP6 channel <a href="http://download.suse.de/download/ibs/SUSE:/SLE-15-SP6:/GA/standard/x86_64/systemd-testsuite-254.5-150600.1.2.x86_64.rpm" class="external">http://download.suse.de/download/ibs/SUSE:/SLE-15-SP6:/GA/standard/x86_64/systemd-testsuite-254.5-150600.1.2.x86_64.rpm</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><code>systemd-testsuite</code> is scheduled in 15-SP6 functional group.</li>
</ul>
<p>Related slack thead: <a href="https://suse.slack.com/archives/C02CSAZLAR4/p1701087663691749" class="external">https://suse.slack.com/archives/C02CSAZLAR4/p1701087663691749</a></p>
openQA Tests - action #136298 (Resolved): Leap Micro test fails in transactional_updatehttps://progress.opensuse.org/issues/1362982023-09-22T06:11:38Zjlausuchjalausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario leap-micro-5.5-MicroOS-Image-x86_64-microos_image_default@64bit fails in<br>
<a href="https://openqa.opensuse.org/tests/3591732/modules/transactional_update/steps/96" class="external">transactional_update</a></p>
<p>As the job says, there should be an expected change when <a href="https://openqa.opensuse.org/tests/3591732#step/transactional_update/23" class="external">installing the local rpm</a><br>
<code>transactional-update -n ptf install update-test-trivial/update-test-security-5.1-1.20.x86_64.rpm</code><br>
and <a href="https://openqa.opensuse.org/tests/3591732#step/transactional_update/73" class="external">adding the utt repo</a> along with <code>transactional-update -n cleanup up</code>. </p>
<p>The local package is <code>/data/microos/utt-opensuse-x86_64.tgz</code> and the repo is <code>/data/microos/utt-leap.repo</code>, both in the data directory:<br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/data/microos" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/data/microos</a></p>
<p>This was working on Leap Micro 5.4 (no existing jobs), so for some reason now the packages seem to be the same or the local rpm is already a higher version than the one in the repo, and zypper says <code>zypper: nothing to update</code>.</p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>MicroOS image boot with ignition disk and default tests. Default tests are transactional-update, rebootmgr, health_check, cockpit service and some other checks specific to MicroOS.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since the beginning.</p>
openQA Tests - action #129601 (Feedback): bootloader_uefi fails too often in aarch64https://progress.opensuse.org/issues/1296012023-05-19T05:49:51Zjlausuchjalausuch@suse.com
<p><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/installation/bootloader_uefi.pm" class="external">installation/bootloader_uefi.pm</a> times out quite often because openQA does not have time to enter uefi grub2 configuration screen before the 10s grub timeout.</p>
<p>e.g. <br>
<a href="https://openqa.suse.de/tests/11157624#step/bootloader_uefi/11">https://openqa.suse.de/tests/11157624#step/bootloader_uefi/11</a><br>
<a href="https://openqa.suse.de/tests/11157620#step/bootloader_uefi/11">https://openqa.suse.de/tests/11157620#step/bootloader_uefi/11</a><br>
<a href="https://openqa.suse.de/tests/11157622#step/bootloader_uefi/11">https://openqa.suse.de/tests/11157622#step/bootloader_uefi/11</a></p>
<p>The culprit is that the first <code>bootloader-grub2</code> takes too long to match.</p>
<p>This is a successful run:</p>
<pre><code>[2023-05-17T22:29:48.135632+02:00] [debug] [pid:78975] <<< testapi::assert_screen(mustmatch=[
"bootloader-shim-import-prompt",
"bootloader-grub2"
], timeout=90)
[2023-05-17T22:29:49.928958+02:00] [warn] [pid:79369] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.82 seconds for 14 candidate needles - make your needles more specific
[2023-05-17T22:29:49.929428+02:00] [debug] [pid:79369] no match: 89.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:29:50.104691+02:00] [debug] [pid:79369] no change: 88.0s
[2023-05-17T22:29:50.588948+02:00] [debug] [pid:79369] no match: 88.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:29:51.105278+02:00] [debug] [pid:79369] no change: 87.0s
[2023-05-17T22:29:51.589146+02:00] [debug] [pid:79369] no match: 87.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:29:52.105972+02:00] [debug] [pid:79369] no change: 86.0s
[2023-05-17T22:29:52.589983+02:00] [debug] [pid:79369] no match: 86.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:00.232487+02:00] [warn] [pid:79369] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 7.13 seconds for 14 candidate needles - make your needles more specific
[2023-05-17T22:30:00.232953+02:00] [debug] [pid:79369] no match: 85.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:00.248237+02:00] [debug] [pid:79369] no change: 77.8s
[2023-05-17T22:30:00.733227+02:00] [debug] [pid:79369] no match: 77.8s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:01.236512+02:00] [debug] [pid:79369] no change: 76.9s
[2023-05-17T22:30:01.743323+02:00] [warn] [pid:79369] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.51 seconds for 14 candidate needles - make your needles more specific
[2023-05-17T22:30:01.743772+02:00] [debug] [pid:79369] no match: 76.9s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:09.594737+02:00] [warn] [pid:79369] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 7.36 seconds for 14 candidate needles - make your needles more specific
[2023-05-17T22:30:09.595227+02:00] [debug] [pid:79369] no match: 75.9s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:10.332028+02:00] [warn] [pid:79369] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.71 seconds for 14 candidate needles - make your needles more specific
[2023-05-17T22:30:10.332520+02:00] [debug] [pid:79369] no match: 68.5s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:11.328004+02:00] [warn] [pid:79369] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.72 seconds for 14 candidate needles - make your needles more specific
[2023-05-17T22:30:11.328472+02:00] [debug] [pid:79369] no match: 67.5s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:12.205373+02:00] [warn] [pid:79369] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.59 seconds for 14 candidate needles - make your needles more specific
[2023-05-17T22:30:12.205867+02:00] [debug] [pid:79369] no match: 66.5s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:19.704649+02:00] [warn] [pid:79369] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 7.09 seconds for 14 candidate needles - make your needles more specific
[2023-05-17T22:30:19.705116+02:00] [debug] [pid:79369] no match: 65.5s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-17T22:30:20.417002+02:00] [debug] [pid:78975] >>> testapi::_handle_found_needle: found bootmenu-jeos-20201204, similarity 1.00 @ 101/208
[2023-05-17T22:30:20.419694+02:00] [debug] [pid:78975] tests/installation/bootloader_uefi.pm:124 called bootloader_setup::uefi_bootmenu_params -> lib/bootloader_setup.pm:383 called testapi::send_key_until_needlematch
[2023-05-17T22:30:20.420160+02:00] [debug] [pid:78975] <<< testapi::check_screen(mustmatch="grub2-enter-edit-mode", timeout=0)
</code></pre>
<p>And this is a failed run:</p>
<pre><code>[2023-05-18T22:31:23.112731+02:00] [debug] [pid:20579] <<< testapi::assert_screen(mustmatch=[
"bootloader-shim-import-prompt",
"bootloader-grub2"
], timeout=90)
[2023-05-18T22:31:24.904170+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.82 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:24.904637+02:00] [debug] [pid:21382] no match: 89.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:25.081871+02:00] [debug] [pid:21382] no change: 88.0s
[2023-05-18T22:31:25.580143+02:00] [debug] [pid:21382] no match: 88.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:26.094924+02:00] [debug] [pid:21382] no change: 87.0s
[2023-05-18T22:31:26.569793+02:00] [debug] [pid:21382] no match: 87.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:27.083393+02:00] [debug] [pid:21382] no change: 86.0s
[2023-05-18T22:31:27.553981+02:00] [debug] [pid:21382] no match: 86.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:35.276260+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 7.19 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:35.276731+02:00] [debug] [pid:21382] no match: 85.0s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:36.083159+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.78 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:36.083646+02:00] [debug] [pid:21382] no match: 77.8s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:36.279755+02:00] [debug] [pid:21382] no change: 76.8s
[2023-05-18T22:31:37.020384+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.74 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:37.020854+02:00] [debug] [pid:21382] no match: 76.8s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:44.628366+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 7.35 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:44.628834+02:00] [debug] [pid:21382] no match: 75.8s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:45.401250+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.74 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:45.401731+02:00] [debug] [pid:21382] no match: 68.4s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:46.386500+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.74 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:46.386994+02:00] [debug] [pid:21382] no match: 67.4s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:47.387270+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.74 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:47.387869+02:00] [debug] [pid:21382] no match: 66.4s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:55.130059+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 7.48 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:55.130529+02:00] [debug] [pid:21382] no match: 65.4s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:55.715449+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.56 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:55.715931+02:00] [debug] [pid:21382] no match: 57.9s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:31:56.143795+02:00] [debug] [pid:21382] no change: 56.9s
[2023-05-18T22:31:56.669176+02:00] [warn] [pid:21382] !!! backend::baseclass::check_asserted_screen: check_asserted_screen took 0.52 seconds for 14 candidate needles - make your needles more specific
[2023-05-18T22:31:56.669652+02:00] [debug] [pid:21382] no match: 56.9s, best candidate: bootloader_uefi-20210917 (0.00)
[2023-05-18T22:32:04.606465+02:00] [debug] [pid:20579] >>> testapi::_handle_found_needle: found bootmenu-jeos-20201204, similarity 1.00 @ 101/208
[2023-05-18T22:32:04.610142+02:00] [debug] [pid:20579] tests/installation/bootloader_uefi.pm:124 called bootloader_setup::uefi_bootmenu_params -> lib/bootloader_setup.pm:383 called testapi::send_key_until_needlematch
[2023-05-18T22:32:04.610684+02:00] [debug] [pid:20579] <<< testapi::check_screen(mustmatch="grub2-enter-edit-mode", timeout=0)
</code></pre>
<p>So, in the first case, the needle takes around 25s to be matched after the VM is started, but in the second case it takes ~45s, which makes the grub to pick the default option and boot the system without a chance to go to the <code>grub2-enter-edit-mode</code> screen.</p>
ALP - action #126716 (Resolved): test fails in run_container_in_k3s - /usr/bin/k3s-install: No su...https://progress.opensuse.org/issues/1267162023-03-27T13:48:34Zjlausuchjalausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario alp-micro-0.1-Default-x86_64-k3s@64bit fails in<br>
<a href="https://openqa.opensuse.org/tests/3194054/modules/run_container_in_k3s/steps/17" class="external">run_container_in_k3s</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>The base test suite is used for job templates defined in YAML documents. It has no settings of its own.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.opensuse.org/tests/3183089" class="external">5.2</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: (unknown) (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=alp&flavor=Default&machine=64bit&test=k3s&version=micro-0.1" class="external">latest</a></p>
ALP - action #125855 (Resolved): Create OBS-sync scripts for ALP Micro and Bedrockhttps://progress.opensuse.org/issues/1258552023-03-13T07:52:34Zjlausuchjalausuch@suse.com
<p>Create new sync scripts in <a href="https://github.com/os-autoinst/openqa-trigger-from-obs" class="external">openqa-trigger-from-obs</a></p>
<p>Currently we have 2 sync scripts that we used for the ALP December prototype:<br>
<a href="https://github.com/os-autoinst/openqa-trigger-from-obs/blob/master/xml/obs/SUSE:ALP:ToTest.xml" class="external">https://github.com/os-autoinst/openqa-trigger-from-obs/blob/master/xml/obs/SUSE:ALP:ToTest.xml</a><br>
<a href="https://github.com/os-autoinst/openqa-trigger-from-obs/blob/master/xml/obs/SUSE:ALP:Staging.xml" class="external">https://github.com/os-autoinst/openqa-trigger-from-obs/blob/master/xml/obs/SUSE:ALP:Staging.xml</a></p>
<p>But this project in IBS is obsolete and we should now sync the new images from the 2 new IBS projects:<br>
<a href="https://build.opensuse.org/project/show/SUSE:ALP:Products:Micro:0.1" class="external">https://build.opensuse.org/project/show/SUSE:ALP:Products:Micro:0.1</a><br>
<a href="https://build.opensuse.org/project/show/SUSE:ALP:Products:Bedrock:0.1" class="external">https://build.opensuse.org/project/show/SUSE:ALP:Products:Bedrock:0.1</a></p>
<p><a href="https://download.opensuse.org/repositories/SUSE:/ALP:/Products:/" class="external">https://download.opensuse.org/repositories/SUSE:/ALP:/Products:/</a></p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li>Create new sync script for ALP Micro in <a href="https://github.com/os-autoinst/openqa-trigger-from-obs" class="external">openqa-trigger-from-obs</a></li>
<li>Create new sync script for ALP Bedrock in <a href="https://github.com/os-autoinst/openqa-trigger-from-obs" class="external">openqa-trigger-from-obs</a></li>
</ul>
ALP - action #125852 (Resolved): Create 2 new job groups in openqa.opensuse.org to hold the 2 new...https://progress.opensuse.org/issues/1258522023-03-13T07:44:11Zjlausuchjalausuch@suse.com
<p>So far, we have been using a <a href="https://openqa.opensuse.org/group_overview/100" class="external">job group</a> for ALP images, but that product in IBS is obsolete.</p>
<p>Instead, we now have 2 flavors corresponding to the 2 new products (see epic).</p>
<p>For now, we can keep the set of test suites the same as we had for ALP December, and we can do modifications as needed.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li>Create 2 new jobs in O3: <code>ALP-Micro</code> and <code>ALP-Bedrock</code></li>
<li>Create corresponding mediums</li>
<li>Create the content of the groups in <a href="https://github.com/os-autoinst/opensuse-jobgroups" class="external">opensuse-jobgroups</a></li>
</ul>
ALP - coordination #125846 (Resolved): [epic] March Prototype testinghttps://progress.opensuse.org/issues/1258462023-03-13T07:20:30Zjlausuchjalausuch@suse.com
<p>For March prototype we have a 2 main deliverables:</p>
<ul>
<li><a href="https://confluence.suse.com/display/LEONG/01+SUSE+ALP+Bedrock" class="external">ALP Bedrock</a></li>
<li><a href="https://confluence.suse.com/display/LEONG/03+SUSE+ALP+Micro" class="external">ALP Micro</a></li>
</ul>
<p>Bedrock is like generic server-flavor OS and Micro is similar to SLE Micro or MicroOS flavor with limited set of packages.</p>
<p>QE Department has to provide test coverage for all the <a href="https://jira.suse.com/issues/?jql=project%20%3D%20PED%20AND%20fixVersion%20%3D%20%22ALP%20March%20Prototype%22" class="external">features</a> and all the images in the 2 flavors.</p>
<p>This epic aims to collect all the needed tickets related to March prototype testing.</p>
openQA Tests - action #116257 (New): [virtualization][svirt] Some workers in openqaworker2 time o...https://progress.opensuse.org/issues/1162572022-09-06T06:57:39Zjlausuchjalausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-12-SP5-JeOS-for-kvm-and-xen-Updates-x86_64-jeos-extratest@svirt-xen-hvm fails in<br>
<a href="https://openqa.suse.de/tests/9459035/modules/bootloader_svirt/steps/25" class="external">bootloader_svirt</a></p>
<p>It hits the <code>MAX_JOB_TIMEOUT</code> while trying to copy the image. </p>
<p>The affected workers are:<br>
<a href="https://openqa.suse.de/admin/workers/366" class="external">openqaworker2:9</a><br>
<a href="https://openqa.suse.de/admin/workers/980" class="external">openqaworker2:10</a><br>
<a href="https://openqa.suse.de/admin/workers/1252" class="external">openqaworker2:16</a></p>
<p>Most jobs using these workers time out during this step. Other examples:<br>
<a href="https://openqa.suse.de/tests/9459036" class="external">https://openqa.suse.de/tests/9459036</a><br>
<a href="https://openqa.suse.de/tests/9459031" class="external">https://openqa.suse.de/tests/9459031</a><br>
<a href="https://openqa.suse.de/tests/9459037" class="external">https://openqa.suse.de/tests/9459037</a><br>
<a href="https://openqa.suse.de/tests/9459064" class="external">https://openqa.suse.de/tests/9459064</a><br>
<a href="https://openqa.suse.de/tests/9459069" class="external">https://openqa.suse.de/tests/9459069</a></p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/9459035" class="external">20220905-1</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/9450196" class="external">20220903-1</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=JeOS-for-kvm-and-xen-Updates&machine=svirt-xen-hvm&test=jeos-extratest&version=12-SP5" class="external">latest</a></p>
ALP - action #114935 (Resolved): Add standard container host tests for ALP prototype in O3https://progress.opensuse.org/issues/1149352022-08-03T07:39:42Zjlausuchjalausuch@suse.com
<p>There are currently no container tests for ALP prototype.</p>
<p>The idea is to enable the same set of tests that are run for MicroOS/Leap-Micro, e.g. <a href="https://openqa.opensuse.org/tests/2433988" class="external">https://openqa.opensuse.org/tests/2433988</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria:<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<p>Create a new jobs <code>alp_containers</code> for the flavors <code>kvm-and-xen</code> and <code>kvm-and-xen_NonTransactional</code> which schedules the following modules:</p>
<pre><code>- toolbox
- podman
- image_podman
- podman_3rd_party_images
- podman_pods
- rootless_podman
</code></pre> openQA Project - action #113219 (Closed): Create a master label at job group level to label all t...https://progress.opensuse.org/issues/1132192022-07-04T18:53:37Zjlausuchjalausuch@suse.com
<p>As a openQA user, I would like to have a feature to label all the jobs of the same build at the same time with certain <code>bsc</code> or <code>poo</code>, instead of labeling one by one.</p>
<p>A possible use case is in container image tests (BCI) where a new container image build is tested on multiple host versions and architectures to be validated. Sometimes, the image is faulty and we need to label all the jobs (~40) which makes thing very time consuming for the reviewer.<br>
For example, <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP4&build=7.12_pcp-image&groupid=445" class="external">this build</a> or <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP4&build=7.9_pcp-image&groupid=445" class="external">this</a> are mostly failed tests.</p>
<p>It would be nice to use the <code>tag</code> feature + the <code>build</code> number doing something like this:<br>
<img src="https://progress.opensuse.org/attachments/download/13487/Screenshot%202022-07-04%20at%2020.52.21.png" alt="" loading="lazy" /><br>
and automatically label all the jobs.</p>
ALP - action #112895 (Closed): [stale] SelfInstall ALP Images fail in image_checkshttps://progress.opensuse.org/issues/1128952022-06-22T18:07:31Zjlausuchjalausuch@suse.com
<p><a href="https://openqa.opensuse.org/tests/2430307#step/image_checks/8" class="external">https://openqa.opensuse.org/tests/2430307#step/image_checks/8</a><br>
<a href="https://openqa.opensuse.org/tests/2430327#step/image_checks/9" class="external">https://openqa.opensuse.org/tests/2430327#step/image_checks/9</a></p>
<p>It fails in the step: <br>
<code>validate_script_output("sfdisk --list-free /dev/$disk", qr/Unpartitioned space .* 0 sectors/);</code><br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/microos/image_checks.pm#L26" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/microos/image_checks.pm#L26</a></p>
<pre><code>Unpartitioned space /dev/vda: 27.85 GiB, 29906419200 bytes, 58410975 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Start End Sectors Size
</code></pre>
<p>Expected output:<br>
<a href="https://openqa.opensuse.org/tests/2426647#step/image_checks/6" class="external">https://openqa.opensuse.org/tests/2426647#step/image_checks/6</a></p>
<pre><code>Unpartitioned space /dev/vda: 0 B, 0 bytes, 0 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
</code></pre> ALP - action #112829 (Closed): [stale] ALP uefi jobs fail in disk_boot https://progress.opensuse.org/issues/1128292022-06-21T21:32:51Zjlausuchjalausuch@suse.com
<p>UEFI jobs are not booting properly:<br>
<a href="https://openqa.opensuse.org/tests/2426185" class="external">https://openqa.opensuse.org/tests/2426185</a></p>
<p>Expected result (Leap Micro):<br>
<a href="https://openqa.opensuse.org/tests/2426642#step/disk_boot/1" class="external">https://openqa.opensuse.org/tests/2426642#step/disk_boot/1</a></p>
ALP - action #112826 (Resolved): Fix ALP SelfInstall jobshttps://progress.opensuse.org/issues/1128262022-06-21T21:27:06Zjlausuchjalausuch@suse.com
<p>These jobs fail booting the image:<br>
<a href="https://openqa.opensuse.org/tests/2427880#step/bootloader_uefi/2" class="external">https://openqa.opensuse.org/tests/2427880#step/bootloader_uefi/2</a></p>
<p>Expected result (Leap Micro):<br>
<a href="https://openqa.opensuse.org/tests/2426647#step/bootloader_uefi/3" class="external">https://openqa.opensuse.org/tests/2426647#step/bootloader_uefi/3</a></p>