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> 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> 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>
ALP - action #112427 (Resolved): 5. Adapt transactional server related test cases for ALPhttps://progress.opensuse.org/issues/1124272022-06-14T16:09:51Zjlausuchjalausuch@suse.com
<p>The idea for the first PoC for ALP testing in openQA is to copy what we already have for Leap Micro/MicroOS.<br>
So, taking this job as an example: <a href="https://openqa.opensuse.org/tests/2351803" class="external">https://openqa.opensuse.org/tests/2351803</a><br>
we should basically get the same results but executing them on ALP images.</p>
<p>The used schedule in this case is <a href="https://openqa.opensuse.org/tests/2351803/settings/schedule/sle-micro/raw_image.yaml" class="external">https://openqa.opensuse.org/tests/2351803/settings/schedule/sle-micro/raw_image.yaml</a><br>
But a different approach could be used (e.g <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/products/microos/main.pm" class="external">main.pm</a>).</p>
ALP - action #112424 (Resolved): 4. Enable OBS sync for ALP images for openQAhttps://progress.opensuse.org/issues/1124242022-06-14T16:06:33Zjlausuchjalausuch@suse.com
<p>To be able to trigger new openQA test for every build of ALP images, we need to enable this configuration into <a href="https://github.com/os-autoinst/openqa-trigger-from-obs" class="external">https://github.com/os-autoinst/openqa-trigger-from-obs</a>.</p>
<p>The OBS project to sync is: <code>devel:LEO/ALP</code>: <a href="https://build.opensuse.org/package/show/devel:LEO/ALP" class="external">https://build.opensuse.org/package/show/devel:LEO/ALP</a><br>
The images are available for download here: <a href="https://download.opensuse.org/repositories/devel:/LEO/images/" class="external">https://download.opensuse.org/repositories/devel:/LEO/images/</a><br>
We need to sync the following flavors (for now):</p>
<ul>
<li>kvm-and-xen</li>
<li>kvm-and-xen_NonTransactional</li>
<li>SelfInstall</li>
<li>SelfInstall_NonTransactional</li>
</ul>
<p>and also sync the repository so that we can use the <code>SCC_URL</code> variable pointing to local assets.</p>
ALP - action #112421 (Resolved): 3. Create a new product in os-autoinst-distri-opensusehttps://progress.opensuse.org/issues/1124212022-06-14T16:03:47Zjlausuchjalausuch@suse.com
<p>Since we are going to use <code>DISTRI=alp</code> for new ALP tests in openQA, we need to add the product to<br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/products" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/products</a><br>
And also in O3 machine (ariel).</p>
<pre><code>/var/lib/openqa/share/tests> ll
total 4
lrwxrwxrwx 1 geekotest nogroup 8 Apr 5 10:34 d-installer -> opensuse
lrwxrwxrwx 1 root root 8 Sep 4 2017 kubic -> opensuse
lrwxrwxrwx 1 geekotest nogroup 8 Mar 30 15:36 leap-micro -> opensuse
lrwxrwxrwx 1 geekotest nogroup 8 Apr 16 2019 microos -> opensuse
drwxr-xr-x 5 geekotest nogroup 121 Feb 11 2020 obs
lrwxrwxrwx 1 root root 6 Jan 16 2019 openQA -> openqa
drwxr-xr-x 6 geekotest nogroup 166 Oct 11 2021 openqa
drwxr-xr-x 15 geekotest nogroup 4096 Jun 13 12:08 opensuse
drwxr-xr-x 4 geekotest nogroup 65 Apr 16 2020 repositories
lrwxrwxrwx 1 root root 8 Jul 22 2016 windows -> opensuse
</code></pre>
<p>we would need another symlinc to <code>alp -> opensuse</code>.</p>