openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-01-17T08:59:42ZopenSUSE Project Management Tool
Redmine 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 #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 #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>
openQA Project - action #111314 (Workable): _SECRET_ variables are exposed in vars.json when the ...https://progress.opensuse.org/issues/1113142022-05-19T11:03:37Zjlausuchjalausuch@suse.com
<p>Some workers contain sensitive information using <code>_SECRET</code> variables. Those variables are hidden in the settings tab and in vars.json, as expected.<br>
However, if you restart or clone a job and cancel it while it's running, those variables are exposed in vars.json</p>
<p><img src="https://progress.opensuse.org/attachments/download/13268/vars.png" alt="" loading="lazy" /></p>
<p>NOTE: I don't want to provide links as I might give too many hints for a public place.</p>
openQA Project - action #111135 (New): Enhance email notification message content for about faile...https://progress.opensuse.org/issues/1111352022-05-16T07:57:05Zjlausuchjalausuch@suse.com
<p>The new feature introduced by <a href="https://progress.opensuse.org/issues/91605" class="external">https://progress.opensuse.org/issues/91605</a> is very useful to notify people in different ways (direct email or to Slack, which will turn into Slack message). However, those messages could be improved adding some extra information about the test name, the group name, etc.</p>
<p>This is an example of how a message in Slack looks like:<br>
<img src="https://progress.opensuse.org/attachments/download/13239/slack_message.png" alt="" loading="lazy" /></p>
<p>So, a proposal from my side could be:</p>
<pre><code>Unknown issue to be reviewed.
OpenQA test https://openqa.suse.de/tests/8762619 fails with
"Test died: script timeout: docker info at /usr/lib/os-autoinst/distribution.pm line 296."
</code></pre>
<p>I guess it's difficult to include the reason given by the failure, so something like this could be also helpful:</p>
<pre><code>Unknown issue to be reviewed.
OpenQA test https://openqa.suse.de/tests/8762619 fails in docker.
Job Group: 427 - Maintenance: Test Repo / Public Cloud Maintenance Updates
Build: 20220515-1
Flavor: AZURE-CHOST-BYOS-Updates
</code></pre>
<p>similar to when you report a poo ticket directly from the UI. </p>
openQA Tests - action #111093 (New): [containers][sporadic][s389x] test fails in boot_to_desktop ...https://progress.opensuse.org/issues/1110932022-05-13T13:22:29Zjlausuchjalausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-BCI-Updates-s390x-bci_on_SLES_15-SP2_host_docker@s390x-kvm-sle12 fails in<br>
<a href="https://openqa.suse.de/tests/8753928/modules/boot_to_desktop/steps/28" class="external">boot_to_desktop</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.suse.de/tests/8753928" class="external">_15-SP4_10.47_minimal-image</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/8744352" class="external">_15-SP4_3.9_python-3.10-image</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=s390x&distri=sle&flavor=BCI-Updates&machine=s390x-kvm-sle12&test=bci_on_SLES_15-SP2_host_docker&version=15-SP4" class="external">latest</a></p>
openQA Tests - action #109046 (Resolved): [tools] auto_review:"Unable to find image SLES15-SP3-Je...https://progress.opensuse.org/issues/1090462022-03-28T06:23:08Zjlausuchjalausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Migration-from-SLE12-SPx-s390x-offline_sles12sp3_ltss_pscc_asmm-lgm_all_full@s390x-kvm-sle15 fails in<br>
<a href="https://openqa.suse.de/tests/8415599/modules/bootloader_zkvm/steps/18" class="external">bootloader_zkvm</a><br>
But the qcow exists:</p>
<pre><code>$ /var/lib/openqa/share/factory/hdd/fixed> ll SLES-12-SP3-s390x-GM-gnome-allpatterns.qcow2
-rw-r--r-- 1 geekotest nogroup 14485946368 Jan 14 08:45 SLES-12-SP3-s390x-GM-gnome-allpatterns.qcow2
</code></pre>
<p>And the asset is actually there:<br>
<img src="https://progress.opensuse.org/attachments/download/13001/hdd.png" alt="" loading="lazy" /></p>
<p>It happens in all jobs with <code>svirt</code> backend that have their HDD in fixed directory. So, all s390x jobs and some others that use that backend too:<br>
Examples:<br>
<a href="https://openqa.suse.de/tests/8414273" class="external">https://openqa.suse.de/tests/8414273</a><br>
<a href="https://openqa.suse.de/tests/8414268" class="external">https://openqa.suse.de/tests/8414268</a><br>
<a href="https://openqa.suse.de/tests/8414272" class="external">https://openqa.suse.de/tests/8414272</a><br>
<a href="https://openqa.suse.de/tests/8414267" class="external">https://openqa.suse.de/tests/8414267</a><br>
<a href="https://openqa.suse.de/tests/8414271" class="external">https://openqa.suse.de/tests/8414271</a><br>
<a href="https://openqa.suse.de/tests/8414266" class="external">https://openqa.suse.de/tests/8414266</a><br>
<a href="https://openqa.suse.de/tests/8414270" class="external">https://openqa.suse.de/tests/8414270</a><br>
<a href="https://openqa.suse.de/tests/8414265" class="external">https://openqa.suse.de/tests/8414265</a><br>
<a href="https://openqa.suse.de/tests/8414269" class="external">https://openqa.suse.de/tests/8414269</a><br>
<a href="https://openqa.suse.de/tests/8414264" class="external">https://openqa.suse.de/tests/8414264</a></p>
<p><a href="https://openqa.suse.de/tests/8414323" class="external">https://openqa.suse.de/tests/8414323</a><br>
<a href="https://openqa.suse.de/tests/8414322" class="external">https://openqa.suse.de/tests/8414322</a><br>
<a href="https://openqa.suse.de/tests/8414321" class="external">https://openqa.suse.de/tests/8414321</a><br>
<a href="https://openqa.suse.de/tests/8414320" class="external">https://openqa.suse.de/tests/8414320</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.suse.de/tests/8345312" class="external">113.1</a></p>
<p>Find jobs referencing this ticket with the help of<br>
<a href="https://raw.githubusercontent.com/os-autoinst/scripts/master/openqa-query-for-job-label" class="external">https://raw.githubusercontent.com/os-autoinst/scripts/master/openqa-query-for-job-label</a> ,<br>
call <code>openqa-query-for-job-label poo#109046</code></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/8292036" class="external">108.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=s390x&distri=sle&flavor=Migration-from-SLE12-SPx&machine=s390x-kvm-sle15&test=offline_sles12sp3_ltss_pscc_asmm-lgm_all_full&version=15-SP4" class="external">latest</a></p>
openQA Tests - action #108953 (Resolved): [tools] Performance issues in some s390 workershttps://progress.opensuse.org/issues/1089532022-03-25T07:13:32Zjlausuchjalausuch@suse.com
<p>This ticket is to collect examples of jobs that are failing due to some performance degradation, specially s390x workers.</p>
<p>Installation jobs:<br>
(some of these issues seem to be a slow key press so it doesn't reach the target needle on time):</p>
<ul>
<li><a href="https://openqa.suse.de/tests/8390044#step/select_patterns/5" class="external">https://openqa.suse.de/tests/8390044#step/select_patterns/5</a> - grenache-1:47</li>
<li><a href="https://openqa.suse.de/tests/8387127#step/disable_grub_timeout/18" class="external">https://openqa.suse.de/tests/8387127#step/disable_grub_timeout/18</a> - grenache-1:32</li>
<li><a href="https://openqa.suse.de/tests/8380005#step/add_update_test_repo/38" class="external">https://openqa.suse.de/tests/8380005#step/add_update_test_repo/38</a> - grenache-1:49
<a href="https://openqa.suse.de/tests/8380706#step/add_update_test_repo/10" class="external">https://openqa.suse.de/tests/8380706#step/add_update_test_repo/10</a> - grenache-1:49 </li>
<li><a href="https://openqa.suse.de/tests/8380553#step/cleanup_before_shutdown/4" class="external">https://openqa.suse.de/tests/8380553#step/cleanup_before_shutdown/4</a> (command 'rm -f /etc/udev/rules.d/70-persistent-net.rules' timed out ) - grenache-1:37</li>
</ul>
<p>Other jobs:</p>
<ul>
<li><a href="https://openqa.suse.de/tests/8387144#step/install_updates/14" class="external">https://openqa.suse.de/tests/8387144#step/install_updates/14</a> (command 'rm /tmp/journal_before' timed out) - grenache-1:44</li>
<li><a href="https://openqa.suse.de/tests/8387142#step/image_checks/13" class="external">https://openqa.suse.de/tests/8387142#step/image_checks/13</a> (script timeout: cat /usr/share/combustion-welcome) - grenache-1:33 </li>
</ul>
<p>Boot failures:</p>
<ul>
<li><a href="https://openqa.suse.de/tests/8380156#step/bootloader_zkvm/23" class="external">https://openqa.suse.de/tests/8380156#step/bootloader_zkvm/23</a></li>
<li><a href="https://openqa.suse.de/tests/8380915#step/bootloader_zkvm/22" class="external">https://openqa.suse.de/tests/8380915#step/bootloader_zkvm/22</a></li>
</ul>
openQA Project - action #108824 (Resolved): Some of the daily aggregate tests are cancelled witho...https://progress.opensuse.org/issues/1088242022-03-24T07:02:27Zjlausuchjalausuch@suse.com
<p>Some of the tests that are triggered by the bot-ng are cancelled without any apparent reason and missing logs.</p>
<p>Examples:<br>
<a href="https://openqa.suse.de/tests/8379473" class="external">https://openqa.suse.de/tests/8379473</a><br>
<a href="https://openqa.suse.de/tests/8379476" class="external">https://openqa.suse.de/tests/8379476</a></p>
<p>I have observed this a few times in past days, but I thought it was a sporadic error.<br>
Let's use this ticket to collect these kind of failures.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: It is clear what the expected scheduling behavior is (e.g. is VERSION <em>supposed</em> to be 5.1 in the job despite VERSION 5.0 being specified when scheduling the product)</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Clarify with the author of the test - this test is very new
<ul>
<li>Initial hypothesis: Have these jobs <em>not</em> been scheduled by bot-ng?</li>
<li>Find a way to distinguish bot jobs better</li>
<li>Find out why affected jobs are scheduled with 5.0 but show VERSION 5.1 in the settings</li>
</ul></li>
<li><a href="https://gitlab.suse.de/qac/qac-openqa-yaml/-/blob/master/sle-micro/updates.yaml#L170" class="external">https://gitlab.suse.de/qac/qac-openqa-yaml/-/blob/master/sle-micro/updates.yaml#L170</a>
<ul>
<li>Examine bot-ng logs for scheduling the sle-micro, look for both 5.0 and 5.1 versions (the other one could obsolete the first one)</li>
<li>Product log for 5.0 scheduling: <a href="https://openqa.suse.de/admin/productlog?id=886973" class="external">https://openqa.suse.de/admin/productlog?id=886973</a></li>
<li>Product log for 5.1 scheduling: <a href="https://openqa.suse.de/admin/productlog?id=886978" class="external">https://openqa.suse.de/admin/productlog?id=886978</a></li>
</ul></li>
<li>If the bot cancells jobs as expected, comment "Cancelled because of job #foo" on relevant jobs</li>
</ul>
openQA Tests - action #95697 (New): [kernel][jeos][opensuse] Have a common way to add LTP reposit...https://progress.opensuse.org/issues/956972021-07-20T08:34:37Zjlausuchjalausuch@suse.com
<p>Currently, LTP tests in SLE use QA_HEAD_REPO variable<br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/kernel/install_ltp.pm" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/kernel/install_ltp.pm</a></p>
<pre><code> if (is_sle) {
add_qa_head_repo;
return;
}
</code></pre>
<p>Then, for openSUSE, the openSUSE tests, the condition is a bit complex:</p>
<pre><code> my $arch = '';
$arch = "_PowerPC" if is_ppc64le();
$arch = "_zSystems" if is_s390x();
$arch = ((is_x86_64 || is_aarch64) ? "Tumbleweed" : "Factory") . $arch;
$repo = "https://download.opensuse.org/repositories/benchmark:/ltp:/devel/openSUSE_$arch/";
</code></pre>
<p>and even more complex after <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12902" class="external">this PR</a>.</p>
<p>The idea behind this ticket is to use the same function (e.g. <code>add_qa_head_repo</code>) for ALL distri/versions using a single variable (e.g. <code>QA_HEAD_REPO</code>) pointing to the repository to be used, instead of hardcoding the repository with several conditions in the code. This would affect all the kernel jobs (also for JeOS-kernel jobs) for TW and Leap in O3.</p>
openQA Tests - action #93339 (Resolved): test fails in validate_btrfshttps://progress.opensuse.org/issues/933392021-06-01T09:16:42Zjlausuchjalausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP3-Server-DVD-Updates-x86_64-sle_image_on_sle_host@64bit fails in<br>
<a href="https://openqa.suse.de/tests/6149331/modules/validate_btrfs/steps/39" class="external">validate_btrfs</a><br>
Other failures:<br>
All Container jobs, e.g. <a href="https://openqa.suse.de/tests/6151606" class="external">https://openqa.suse.de/tests/6151606</a><br>
All Public Cloud jobs, e.g. <a href="https://openqa.suse.de/tests/6149926#step/validate_btrfs/39" class="external">https://openqa.suse.de/tests/6149926#step/validate_btrfs/39</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.suse.de/tests/6149331" class="external">20210601-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: (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.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Server-DVD-Updates&machine=64bit&test=sle_image_on_sle_host&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #89287 (Resolved): test fails in yast2_lanhttps://progress.opensuse.org/issues/892872021-03-01T14:48:17Zjlausuchjalausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP3-JeOS-for-MS-HyperV-x86_64-jeos-main@svirt-hyperv fails in<br>
<a href="https://openqa.suse.de/tests/5552124/modules/yast2_lan/steps/21" class="external">yast2_lan</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<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/5462492" class="external">23.32</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.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=JeOS-for-MS-HyperV&machine=svirt-hyperv&test=jeos-main&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #58220 (Resolved): [kernel] fadump LVM test failshttps://progress.opensuse.org/issues/582202019-10-15T20:25:44Zjlausuchjalausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Failure when going into grub screen<br>
<a href="https://openqa.suse.de/tests/3479900#step/kdump_and_crash/64" class="external">grub screen</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Maintainer: Petr Cervinka <a href="mailto:pcervinka@suse.com">pcervinka@suse.com</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/3479900" class="external">0358</a><br>
But it also failed in some <a href="https://openqa.suse.de/tests/3395111" class="external">older run</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>This is an example of <a href="https://openqa.suse.de/tests/3470330#step/kdump_and_crash/64" class="external">successful run</a> in the previous build.</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
openQA Project - action #40415 (Resolved): Concurrent jobs with dependencies don't work if they a...https://progress.opensuse.org/issues/404152018-08-29T11:44:49Zjlausuchjalausuch@suse.com
<a name="Reproducibility"></a>
<h1 >Reproducibility:<a href="#Reproducibility" class="wiki-anchor">¶</a></h1>
<p>We have 2 jobs, let's say PARENT and CHILD, where CHILD has PARALLEL_WITH=PARENT.</p>
<p>I have created 2 tests that are on the same machine "64bit", qemu with some other options:<br>
<a href="http://fromm.arch.suse.de/tests/1394" class="external">http://fromm.arch.suse.de/tests/1394</a><br>
<a href="http://fromm.arch.suse.de/tests/1395" class="external">http://fromm.arch.suse.de/tests/1395</a></p>
<p>The parent job needs the child ID for the mutex command:</p>
<pre><code>my $children = get_children();
my $child_id = (keys %$children)[0];
...
script_run("echo Waiting for child with child_id=$child_id");
mutex_wait("child_ready", $child_id);
</code></pre>
<p>This is one line of the parent's output:</p>
<pre><code>Waiting for child with child_id=1399
</code></pre>
<p>Everything OK so far. CHILD recognizes PARENT as its parent and locking api works without problems.</p>
<p>Then, I have created another machine "64bit-other" with the exact same characteristics as the other one. <a href="http://fromm.arch.suse.de/admin/machines" class="external">http://fromm.arch.suse.de/admin/machines</a><br>
And assign CHILD to "64bit-other" in the job group. </p>
<p>The result is that CHILD doesn't have the parent job in the settings panel any more, and the PARENT's output is now:</p>
<pre><code>Waiting for child with child_id=
</code></pre>
<p>Therefore, the command </p>
<pre><code>mutex_wait("child_ready", $child_id);
</code></pre>
<p>waits forever.</p>
<p>Why having different machines? Well, for virtual jobs it doesn't make sense, but for BareMetal jobs like NFV and InfiniBand tests we are using different workers and machines:<br>
ipmi-sonic and ipmi-tails with different worker classes: 64bit-mlx_con5_sonic and 64bit-mlx_con5_tails respectively. </p>