openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-10-09T09:10:00ZopenSUSE Project Management Tool
Redmine openQA Tests - action #137612 (New): [tools][qem] Incomplete test run in S390x with the error me...https://progress.opensuse.org/issues/1376122023-10-09T09:10:00Zdvenkatachala
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Server-DVD-Updates-s390x-Build20231008-1-qam-minimal+base-installation@s390x-kvm incomplete, stops at<br>
<a href="https://openqa.suse.de/tests/12426975#step/installation/9" class="external">installation</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</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/12425401" class="external">20231008-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/12419865" class="external">20231007-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=Server-DVD-Updates&machine=s390x-kvm&test=mru-install-minimal-with-addons&version=15-SP4" class="external">latest</a></p>
<pre><code>[2023-10-09T10:14:56.315767+02:00] [info] [pid:114157] ::: backend::baseclass::die_handler: Backend process died, backend errors are reported below in the following lines:
Error connecting to VNC server <s390kvm097.oqa.prg2.suse.org:5901>: IO::Socket::INET: connect: No route to host
[2023-10-09T10:14:56.316569+02:00] [debug] [pid:114157] Closing SSH serial connection with s390zl13.oqa.prg2.suse.org
[2023-10-09T10:14:56.316960+02:00] [debug] [pid:114157] Destroying openQA-SUT-8 virtual machine
</code></pre> openQA Tests - action #135881 (New): [tools][ppc64le][qemu-backend]openqa fails to publish qcow2 ...https://progress.opensuse.org/issues/1358812023-09-18T08:40:54Zrfan1richard.fan@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p><a href="https://openqa.suse.de/tests/12161670">https://openqa.suse.de/tests/12161670</a><br>
From the test log, it can not complete due to error messages as below:</p>
<pre><code class="html syntaxhl" data-language="html">[2023-09-18T08:09:11.039556+02:00] [debug] [pid:25632] running `nice ionice qemu-img convert -c -O qcow2 /var/lib/openqa/pool/2/raid/hd0-overlay4 assets_public/SLES-15-SP6-ppc64le-Build20.1-12SP5-15-SP4-ph0.qcow2`
[2023-09-18T08:09:11.132952+02:00] [debug] [pid:25632] qemu-img: Could not open '/var/lib/openqa/pool/2/raid/hd0-overlay4': Could not open backing file: Could not open backing file: Could not open backing file: Could not open backing file: Could not open backing file: Could not open '/var/lib/openqa/pool/2/SLES-12-SP5-ppc64le-GM-allpatterns.qcow2': No such file or directory
[2023-09-18T08:09:11.133967+02:00] [warn] [pid:25632] !!! bmwqemu::serialize_state: unable to extract assets: runcmd 'nice ionice qemu-img convert -c -O qcow2 /var/lib/openqa/pool/2/raid/hd0-overlay4 assets_public/SLES-15-SP6-ppc64le-Build20.1-12SP5-15-SP4-ph0.qcow2' failed with exit code 1: 'qemu-img: Could not open '/var/lib/openqa/pool/2/raid/hd0-overlay4': Could not open backing file: Could not open backing file: Could not open backing file: Could not open backing file: Could not open backing file: Could not open '/var/lib/openqa/pool/2/SLES-12-SP5-ppc64le-GM-allpatterns.qcow2': No such file or directory' at /usr/lib/os-autoinst/osutils.pm line 89.
osutils::runcmd("nice", "ionice", "qemu-img", "convert", "-c", "-O", "qcow2", "/var/lib/openqa/pool/2/raid/hd0-overlay4", ...) called at /usr/lib/os-autoinst/OpenQA/Qemu/Proc.pm line 329
OpenQA::Qemu::Proc::export_blockdev_images(OpenQA::Qemu::Proc=HASH(0x1000f309f70), qr(^hd0$)u, "assets_public", "SLES-15-SP6-ppc64le-Build20.1-12SP5-15-SP4-ph0.qcow2", 1) called at /usr/lib/os-autoinst/backend/qemu.pm line 515
backend::qemu::do_extract_assets(backend::qemu=HASH(0x1000f94e1b8), HASH(0x1000f37c540)) called at /usr/lib/os-autoinst/backend/driver.pm line 79
backend::driver::extract_assets(backend::driver=HASH(0x10011073c98), HASH(0x1000f37c540)) called at /usr/lib/os-autoinst/OpenQA/Isotovideo/Utils.pm line 230
eval {...} called at /usr/lib/os-autoinst/OpenQA/Isotovideo/Utils.pm line 230
OpenQA::Isotovideo::Utils::handle_generated_assets(OpenQA::Isotovideo::CommandHandler=HASH(0x1000f317ce0), 1) called at /usr/bin/isotovideo line 161
eval {...} called at /usr/bin/isotovideo line 122
</code></pre>
<a name="Defects"></a>
<h2 >Defects<a href="#Defects" class="wiki-anchor">¶</a></h2>
<p>So far, I can only hit the issue on ppc64le platform. I think it will impact all power+kvm tests which try to publish qcow2 images.<br>
I will try to monitor next sle15sp6 build to see how many cases are impacted, and then check with POs and tool team experts if we can set a higher priority.</p>
<p>can you please help take a look at it? more detail log can be found at detached file.</p>
openQA auto review - openqa-force-result #134873 (New): [qe-core][tools]test fails in update_inst...https://progress.opensuse.org/issues/1348732023-08-31T02:24:21Zrfan1richard.fan@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP2-Server-DVD-Incidents-Install-aarch64-qam-incidentinstall@aarch64-virtio fails in<br>
<a href="https://10.145.10.207/tests/11954791/modules/update_install/steps/65" class="external">update_install</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>. Incident Installation TEST<br>
MAX_JOB_TIME=9000 due to long texlive update</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://10.145.10.207/tests/11950582" class="external">:30387:amazon-ecs-init</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://10.145.10.207/tests/11948020" class="external">:30381:MozillaFirefox</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://10.145.10.207/tests/latest?arch=aarch64&distri=sle&flavor=Server-DVD-Incidents-Install&machine=aarch64-virtio&test=qam-incidentinstall&version=15-SP2" class="external">latest</a></p>
openQA Infrastructure - action #134492 (Workable): [tools] QA-Power8-2-8247-22L-SN1010D5A is not...https://progress.opensuse.org/issues/1344922023-08-22T10:39:48Zzluo
<p>I checked <a href="https://powerhmc1.arch.suse.de/dashboard/#resources/systems/9d3c4d88-a65a-3ad5-97e0-a3f9147d76fb/logical-partitions" class="external">https://powerhmc1.arch.suse.de/dashboard/#resources/systems/9d3c4d88-a65a-3ad5-97e0-a3f9147d76fb/logical-partitions</a><br>
and started VIOS, 4 LPRS, but LPRS haven't got hard disk assigned.<br>
Maybe Power8 machine got this issue after move? Please check and help, thanks!</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: Members of the tools team can access powerhmc1</li>
<li><strong>AC2</strong>: QA-Power8-2-8247-22L-SN1010D5A is usable</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Do not login too many times ;-)</li>
<li>Ask nsinger or mgriessmeier for access</li>
<li>Document in the wiki how to get access to powerhmc1</li>
</ul>
QA - action #134420 (New): [tools] If no refhost found in chosen location, try different ones in ...https://progress.opensuse.org/issues/1344202023-08-18T09:54:30Zvpelcakvpelcak@suse.com
<p>In UV squad we are using so called locations as a form of load balancing of the load on refhosts.</p>
<p>Each location has refhosts assigned and based on used location in .mtuirc the appropriate group/location of refhosts is being chosen from.</p>
<p>Sometimes the location requires necessary refhosts. In such case another locations should be used as backup.</p>
openQA Tests - action #134357 (Blocked): [tools] kvm test run fails on OW21 and OW22 - but works ...https://progress.opensuse.org/issues/1343572023-08-17T07:26:15Zdimstardimstar@opensuse.org
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario microos-Tumbleweed-MicroOS-Image-x86_64-microos_qemu@64bit fails in<br>
<a href="https://openqa.opensuse.org/tests/3512911/modules/kvm/steps/3" class="external">kvm</a></p>
<p>Did not really spot what is going on - but whenever this runs on OW4, it passes, while it fails on OW21/OW22</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.opensuse.org/tests/3512598" class="external">20230816</a></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.opensuse.org/tests/3509946" class="external">20230815</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.opensuse.org/tests/latest?arch=x86_64&distri=microos&flavor=MicroOS-Image&machine=64bit&test=microos_qemu&version=Tumbleweed" class="external">latest</a></p>
openQA Infrastructure - action #132827 (Workable): [tools][qe-core]test fails in rsync_client/sal...https://progress.opensuse.org/issues/1328272023-07-17T04:05:44Zrfan1richard.fan@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>I can see that some tests are failing due to DNS resolve issue on workers "sapworker*", especially on multi-machine tests.can someone help check?</p>
<p>Some error messages as below:<br>
<a href="https://openqa.suse.de/tests/11593878#step/salt_master/15" class="external">https://openqa.suse.de/tests/11593878#step/salt_master/15</a><br>
<a href="http://openqa.suse.de/tests/11594635#step/rsync_client/12" class="external">http://openqa.suse.de/tests/11594635#step/rsync_client/12</a></p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p><a href="https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&arch=&flavor=&machine=&test=&modules=salt_master%2Crsync_client&module_re=&distri=sle&build=20230716-1&groupid=414#" class="external">Failed test links</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>I Tried with another worker to run the rsync tests without any issue: <a href="http://openqa.suse.de/tests/11594925#dependencies" class="external">http://openqa.suse.de/tests/11594925#dependencies</a></p>
<a name="Rollback-steps"></a>
<h2 >Rollback steps<a href="#Rollback-steps" class="wiki-anchor">¶</a></h2>
<ul>
<li>Add back production worker class on sapworker{1,2,3}, i.e. revert <a href="https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/564" class="external">https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/564</a></li>
<li>Add back "tap" worker class to openqaworker1 and sapworker{1,2,3}</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>May be some network problems with workers "sapworker*", based on my tests [at least for rsync test result], the same test can pass with "worker5" but fail with "sapworker1"</p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>First ensure that all openQA workers have the salt state applied cleanly, e.g. <code>sudo salt --no-color -C 'G@roles:worker' state.apply</code></li>
<li>Maybe the failure can be improved on the os-autoinst side, like a better "die"message/reason</li>
<li>As temporary measure consider disabling the "tap" class from affected workers, e.g. make it tap_pooXXX</li>
<li>Debug multi-machine capabilities according to <a href="http://open.qa/docs/#_verify_the_setup" class="external">http://open.qa/docs/#_verify_the_setup</a></li>
<li>Ensure that our salt states ensure all what is needed to run stable multi-machine tests</li>
<li>Add back production worker classes for all affected machines openqaworker1, sapworker{1-7}</li>
</ul>
QA - action #126113 (New): [tools][metrics] Only show queries in backlogger output that are relev...https://progress.opensuse.org/issues/1261132023-03-16T13:00:07Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>See <a href="https://github.com/os-autoinst/qa-tools-backlog-assistant/pull/35#issuecomment-1470034395" class="external">https://github.com/os-autoinst/qa-tools-backlog-assistant/pull/35#issuecomment-1470034395</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> <a href="https://os-autoinst.github.io/qa-tools-backlog-assistant/" class="external">https://os-autoinst.github.io/qa-tools-backlog-assistant/</a> only shows reports that are relevant for checking SLOs</li>
<li><strong>AC2:</strong> Only data relevant for grafana are output over influxdb</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>See suggestion in <a href="https://github.com/os-autoinst/qa-tools-backlog-assistant/pull/35#issuecomment-1470034395" class="external">https://github.com/os-autoinst/qa-tools-backlog-assistant/pull/35#issuecomment-1470034395</a></li>
</ul>
QA - action #124473 (New): [tools] Automatic regression tests export from openQAhttps://progress.opensuse.org/issues/1244732023-02-14T11:20:03Zvpelcakvpelcak@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>With our progression in automation of regression tests we reached the state that many updates just need the results to be looked up in openQA and linked in our testreports.<br>
That is pretty repetitive manual work which begs for the automation.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> Automation fills the links to the appropriate regression tests in openQA and their result into the testreport of the update.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>This will perhaps require knowledge of our test coverage</li>
<li>Maybe extension of openQA API will be needed</li>
</ul>
openQA Project - coordination #117673 (New): [epic][tools] sporadic "Unable to clone Git reposito...https://progress.opensuse.org/issues/1176732022-10-06T22:28:24Zszarate
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Every so often, the plugins fail to clone a repository for instance <a href="https://progress.opensuse.org/issues/117622#note-1" class="external">#117622#note-</a> </p>
<p><a href="https://openqa.suse.de/tests/9668977#" class="external">https://openqa.suse.de/tests/9668977#</a></p>
<pre><code>[2022-10-06T02:01:46.761898+02:00] [info] ::: OpenQA::Isotovideo::Utils::checkout_git_repo_and_branch: Cloning git URL 'https://github.com/Zaoliang/functional_wheel'
[2022-10-06T02:01:52.973889+02:00] [debug] Cloning into 'functional_wheel'...
fatal: unable to access 'https://github.com/Zaoliang/functional_wheel/': OpenSSL SSL_connect: Connection reset by peer in connection to github.com:443
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: A Plugin can be loaded on demand (maybe requires a bit more thinking, and a bit more of thought into the design)</li>
<li><strong>AC2</strong>: A GH token can be used for authenticated requests (I suspect that we're hitting the rate limit here)</li>
<li><strong>AC3</strong>: Wheels cloning is retried (A maximum retry of N times can be configured in the wheels.yaml)</li>
</ul>
QA - action #115613 (New): [tools] dashboard.qam.suse.de/blocked to show updates by the priority ...https://progress.opensuse.org/issues/1156132022-08-22T13:26:47Zvpelcakvpelcak@suse.com
<p>When testing updates, we have them sorted by their priority in SMELT <a href="https://maintenance.suse.de/overview/" class="external">https://maintenance.suse.de/overview/</a></p>
<p>It would be nice, if this priority was also reflected in the dashboard <a href="https://dashboard.qam.suse.de/blocked" class="external">https://dashboard.qam.suse.de/blocked</a></p>
<p>That way, the priority items at the top will be more visible and easier to prioritize.</p>
QA - action #97505 (New): [qem][tools] embed important IBS comments in the testreportshttps://progress.opensuse.org/issues/975052021-08-25T09:35:26ZVANASTASIADISvasilios.anastasiadis@suse.com
<a name="User-story"></a>
<h2 >User story<a href="#User-story" class="wiki-anchor">¶</a></h2>
<p>Occasionally, engineers from security or coordination want to communicate special information about specific requests to testers. This is already done in the form of IBS comments with specific tags, but since most testers do not check ibs and ibs comments, it would be convenient to have those comments displayed in the testreport.</p>
<p>IBS comments containing important information aimed at the testers always start with <code>QA HINT</code> or <code>QA-HINT</code>. Embedding those comments only should be sufficient.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> comments starting with <code>QA HINT</code> or <code>QA-HINT</code> are copied in the testreport</li>
<li><strong>AC2:</strong> comments are placed somewhere easily noticed by the tester before they start reviewing the request</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ul>
<li>decide where inside the testreport to place the comments </li>
<li>fetch and copy the specified IBS comments to the testreport in the decided location</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>In addition to this, there is a SMELT ticket to highlight such comments in smelt (<a href="https://gitlab.suse.de/tools/smelt/-/issues/720" class="external">https://gitlab.suse.de/tools/smelt/-/issues/720</a>). </p>
QA - action #94600 (New): [tools][mtui] Communicate reduced visibility of openQA incident related...https://progress.opensuse.org/issues/946002021-06-23T13:49:30Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>The <code>Results from openQA incidents jobs:</code> section in a maintenance update's test log shows, as one would expect, the incident jobs related to the incident that is to be tested.<br>
It can happen that engineers testing the incident fall under the impression that the openQA coverage shown in the log is the complete openQA test coverage for that incident.<br>
It should thus be communicated that the <code>openQA incident jobs</code> section does not show the complete test coverage of the incident in openQA, but only a subset of it (the other being in aggregate runs that test the incident).</p>
<p>This should clarify to the engineers that the absence of failed incident jobs in the log does not mean necessarily that there are no other failed jobs related to the incident.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> Communicate that the jobs listed in the log of an update are not the complete set of jobs that test that update</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>One suggestion could be to remove that section from the log and instead link the incident comments (eg <a href="https://maintenance.suse.de/incident/19067/#comments" class="external">https://maintenance.suse.de/incident/19067/#comments</a>) where all jobs related to that incident are listed.</li>
</ul>
openQA Project - action #76813 (New): [tools] Test using svirt backend fails with auto_review:"Er...https://progress.opensuse.org/issues/768132020-10-30T13:59:51Zmkittlermarius.kittler@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<ul>
<li>See title and <a href="https://openqa.suse.de/tests/4913987" class="external">https://openqa.suse.de/tests/4913987</a></li>
<li>At the time of creating the ticket the job has been restarted manually and the clone passed.</li>
</ul>
<pre><code>[2022-01-13T13:57:24.238682+01:00] [warn] !!! consoles::VNC::login: Error connecting to VNC server <10.161.145.92:5901>: IO::Socket::INET: connect: Connection refused
</code></pre>
<a name="Steps-to-reproduce"></a>
<h2 >Steps to reproduce<a href="#Steps-to-reproduce" class="wiki-anchor">¶</a></h2>
<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#76813</code></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 to test reviewers what needs to be done in the next step when reading the reason</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p>This looks like a temporary problem with the svirt host (here <code>openqaw5-xen.qa.suse.de</code>). But it is not clear whether the problem is always temporary and an automatic restart would make sense. I mainly created this ticket so jobs like this one won't show up in auto-review anymore.</p>
<ul>
<li>What workers are affected? Is it openqaworker2 and grenache only? Yes, obviously because only them use the svirt backend this way.</li>
<li>Focus on tests trying to connect to a remote machine</li>
<li>Add better log messages explaining to test reviewers what the message could mean</li>
<li>Make sure the test ends with a proper reason propagated into the job results</li>
</ul>
<a name="Out-of-scope"></a>
<h2 >Out of scope<a href="#Out-of-scope" class="wiki-anchor">¶</a></h2>
<ul>
<li>VNC running on localhost, see <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: Test using svirt backend fails with auto_review:"Error connecting to VNC server.*localhost.*Conne... (Resolved)" href="https://progress.opensuse.org/issues/105882">#105882</a> about that</li>
</ul>
<a name="Workaround"></a>
<h2 >Workaround<a href="#Workaround" class="wiki-anchor">¶</a></h2>
<p>Just retry</p>
openQA Tests - coordination #38819 (Workable): [qe-core][tools][functional][epic] Refactor use of...https://progress.opensuse.org/issues/388192018-07-25T09:33:18Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Currently we use some backends which all need to be treated differently but also share commonalities which are not properly reflected in code, e.g. all backends that do not have a local tty but rely on remote connections to the SUTs.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> No "if's" on multiple specific backends but replace by proper characteristic what these backends share</li>
</ul>