openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-02-15T18:12:36ZopenSUSE Project Management Tool
Redmine openQA Project - action #124652 (Resolved): gtk glitch not showing dialog window decoration on op...https://progress.opensuse.org/issues/1246522023-02-15T18:12:36Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>During our graphical YaST tests we (the qe-yam team) encounter a type of graphic glitch where the screen is not properly refreshed.<br>
Examples can be seen <a href="https://openqa.suse.de/tests/10436703#step/iscsi_client/57" class="external">here</a> and <a href="https://openqa.suse.de/tests/9680782#step/yast2_control_center/96" class="external">here</a></p>
<p>This behavior is sporadic but widespread enough that it has forced qe-yam to apply <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15889" class="external">workarounds</a> to a number of our tests.<br>
Because the conditions allowing the workarounds are not always consistent, we have interest in the root of the issue getting resolved.<br>
Our <a href="https://bugzilla.suse.com/show_bug.cgi?id=1204176" class="external">latest bug entry</a> on the matter has been tagged as WONTFIX because we (qe-yam and the YaST developers) have not found a way to reproduce this glitch outside of the openQA environment.</p>
<p>latest: <a href="https://openqa.suse.de/tests/10499467#step/yast2_lan_restart_vlan/19">https://openqa.suse.de/tests/10499467#step/yast2_lan_restart_vlan/19</a> (glitch does not happen on yast2_control_center on last build but can be seen elsewhere)<br>
last good: <a href="https://openqa.suse.de/tests/5900202#step/yast2_control_center/94">https://openqa.suse.de/tests/5900202#step/yast2_control_center/94</a></p>
<a name="Scope"></a>
<h3 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h3>
<p>aarch64, s390x, x86_64 on SLE 15-SP4 and SLE 15-SP5 (issue is not exclusive on qemu)</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> The graphic glitch does not appear anymore in tests</li>
</ul>
<a name="Problem"></a>
<h2 >Problem<a href="#Problem" class="wiki-anchor">¶</a></h2>
<ul>
<li><p><strong>H1</strong> could be the qemu video adapter</p>
<ul>
<li><strong>H1.1</strong> <strong>REJECTED</strong> could be the specific choice of qemu video adapter</li>
<li><em>E1.1-1</em> <em>DONE</em> Try out the reproducing openQA test with different qemu video adapters -> <em>O1.1-1-1</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-16">#124652#note-16</a> different video
adapters reproduced the same issue</li>
<li><strong>H1.2</strong> maybe can not be reproduced with using special qemu video adapter settings</li>
</ul></li>
<li><p><strong>H2</strong> <strong>REJECTED</strong> only happens in older SLE versions => Current SLE15SP5 affected the same</p>
<ul>
<li><em>E2-1</em> <em>DONE</em> Run the equivalent openQA test on SLE </li>
<li><em>O2-1-1</em> issue observed on SLE15SP4-build31.2+ <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-3">#124652#note-3</a></li>
<li><em>O2-1-2</em> 0/100 failures on SLE15SP3+maintenance updates <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-25">#124652#note-25</a></li>
<li><em>E2-2</em> <em>DONE</em> Run the equivalent openQA test on current Tumbleweed -> <em>O2-2-1</em> Tumbleweed does not reproduce the problem, see <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-26">#124652#note-26</a></li>
<li><em>E2-3</em> <em>DONE</em> Run the equivalent openQA test on current SLE15SP5 -> <em>O2-3-1</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-32">#124652#note-32</a> 5/101 (yast2_security) fails <a href="https://openqa.suse.de/tests/overview?distri=sle&build=glitch_investigation_SP5&version=15-SP5" class="external">SLE15SP5@OSD</a></li>
<li><strong>H2.1</strong> <strong>ACCEPTED</strong> only happens in older SLE versions with newer maintenance updates</li>
<li><em>E2.1-1</em> <em>DONE</em> Run openQA test on SLE15-SP4 -> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-23">#124652#note-23</a> 97% fail rate iscsi_server on SLE15-SP4</li>
<li><em>E2.1-2</em> <em>DONE</em> From <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-24">#124652#note-24</a> Run openQA test on SLE15-SP3 with state of maintenance update from 2 years ago ("last good" <a href="https://openqa.suse.de/tests/5900202#step/yast2_control_center/94">https://openqa.suse.de/tests/5900202#step/yast2_control_center/94</a> from #Motivation) -> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-36">#124652-36</a> 0/100 failures on SLE15SP3GM; 0/100 failures on SLE15SP2+updates -> accept <em>H2.1</em></li>
</ul></li>
<li><p><strong>H3</strong> <strong>ACCEPTED</strong> can only be reproduced in openQA</p>
<ul>
<li><em>E3-1</em> <em>DONE</em> try to reproduce manually -> no one could reproduce manually</li>
<li><strong>H3.1</strong> <strong>REJECTED</strong> can be reproduced on openqa.suse.de regardless of OS version or variant</li>
<li><em>E3.1-1</em> <em>DONE</em> Run openSUSE openQA test on openqa.suse.de -> <em>O3.1-1-1</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-32">#124652#note-32</a> 0/101 fails <a href="https://openqa.suse.de/tests/overview?distri=opensuse&build=glitch_investigation_tw&version=Tumbleweed" class="external">Tumbleweed@OSD</a> + 0/101 <a href="https://openqa.suse.de/tests/overview?distri=opensuse&build=glitch_investigation_leap_sp4&version=15.4" class="external">Leap15.4@OSD</a> + 0/100 <a href="https://openqa.suse.de/tests/overview?distri=opensuse&version=Leap15.5&build=glitch_investigation_leap_sp5" class="external">Leap15.5@OSD</a> vs. 5/101 fails <a href="https://openqa.suse.de/tests/overview?distri=sle&build=glitch_investigation_SP5&version=15-SP5" class="external">SLE15SP5@OSD</a></li>
</ul></li>
<li><p><strong>H4</strong> <strong>ACCEPTED</strong> The test module(s) "iscsi_server/client" are most prone to fail, also shows in other yast modules</p>
<ul>
<li><em>E4-1</em> <em>DONE</em> Gather statistics for different yast modules -></li>
<li><em>O4-1-1</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-11">#124652#note-11</a> the problem was referenced for different modules, e.g. iscsi_server and yast2_security but no clear statistics</li>
<li><em>O4-1-2</em> <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-23">#124652#note-23</a> 97-99% fail rate iscsi_server on SLE15-SP4/5 vs. <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: gtk glitch not showing dialog window decoration on openQA size:M (Resolved)" href="https://progress.opensuse.org/issues/124652#note-32">#124652#note-32</a> 5% yast2_security on SLE15-SP5</li>
</ul></li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>It looks like window decorations are missing from the dialog</li>
<li>The emulated graphics adapter might be causing problems with the window manager</li>
<li>Research what options could be used with the graphics emulation in qemu</li>
<li>Identify the underlying parameter(s) in the openQA environment that can cause this graphical glitch.</li>
<li>Find a last good? We couldn't find one easily?</li>
<li>could be a VNC-related issue? Missing borders may occur there</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p><a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=yast2_gui&version=15-SP5" class="external">Link to latest</a></p>
openQA Project - action #122608 (Resolved): exit code of shell command not received by script_runhttps://progress.opensuse.org/issues/1226082023-01-02T18:41:03Zgeorggkioulis@suse.com
<p>Occasionally, <code>script_run</code> (and <code>assert_script_run</code>) do not receive the exit code from the shell command, even though the command has exited, resulting in a timeout.<br>
This has been noticed on s390x-kvm <a href="https://openqa.suse.de/tests/9951916#step/logs_from_installation_system/6" class="external">here</a> where the ping command returns but still <code>script_run</code> times out.<br>
It is also obvious in <a href="https://openqa.suse.de/tests/10244897#step/logs_from_installation_system/7" class="external">this example</a> where <code>assert_script_run</code> times out, despite the fact that the <code>ls</code> command has returned.<br>
The issue is very sporadic and not easy to debug.</p>
openQA Infrastructure - action #102167 (Resolved): Disk monitoring for s390x z/VM backendhttps://progress.opensuse.org/issues/1021672021-11-09T13:47:32Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>There are multiple recent occasions of openQA s390x z/VM tests failing due to <code>Disk or file space is full</code>, eg in scenario sle-15-SP4-Online-s390x-allpatterns@s390x-zVM-vswitch-l3, on <a href="https://openqa.suse.de/tests/7618985/modules/bootloader_start/steps/30" class="external">bootloader_start</a></p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<p><strong>AC1</strong>: Monitor disk space of the z/VM hypervisor<br>
<strong>AC2</strong>: Trigger a manual or automatic clean-up process</p>
<a name="Other-Suggestions"></a>
<h2 >Other Suggestions<a href="#Other-Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Increase storage size</li>
</ul>
openQA Tests - action #99180 (Resolved): test fails in scc_registration in QR 15-SP3https://progress.opensuse.org/issues/991802021-09-24T10:49:22Zgeorggkioulis@suse.com
<p>After a recent change where the multipath activation pop up appears right after disk activation has been completed, the multipath module needs to precede the registration module in the zfcp jobs.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP3-Online-QR-s390x-zfcp@s390x-zfcp fails in<br>
<a href="https://openqa.suse.de/tests/7215665/modules/scc_registration/steps/5" class="external">scc_registration</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>. Maintainer: QE Yast, mgriessmeier</p>
<p>Installation-only test configuring an s390x ZFCP storage.</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/7141435" class="external">188.16</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.suse.de/tests/6872082" class="external">188.15</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=Online-QR&machine=s390x-zfcp&test=zfcp&version=15-SP3" class="external">latest</a></p>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>Alter the order the schedule so that multipath module precedes the registration.</p>
openQA Tests - action #96992 (Resolved): [qe-core][samba_adcli] Track and softfail all samba_adcl...https://progress.opensuse.org/issues/969922021-08-16T13:47:30Zgeorggkioulis@suse.com
<p>The samba_adcli module fails sporadically in a multitude of different cases.</p>
<ul>
<li>Identify those cases</li>
<li>Create individual poos for those that don't have one and track them</li>
<li>Softfail the sporadic failures so that the test can run without blocking approval of updates.</li>
</ul>
openQA Tests - action #96680 (Resolved): [qe-core] s390qa102.qa.suse.de zfcp issuehttps://progress.opensuse.org/issues/966802021-08-09T14:28:28Zgeorggkioulis@suse.com
<p>The disc_activation module <a href="https://openqa.suse.de/tests/6655178" class="external">fails</a> when the job is assigned to the second worker instance (s390qa102.qa.suse.de)</p>
<p>Bringing the FCP device online with <code>chccwdev -e 0.0.fa00</code> on s390qa102 does not attach the SCSI devices:</p>
<pre><code># lszfcp -PHD
0.0.fa00 host0
Error: No fcp devices found.
# cat /proc/scsi/scsi (shows no SCSI attached devices)
Attached devices:
# dmesg
[ 57.022293] NET: Registered protocol family 32
[ 387.264999] qdio: 0.0.fa00 ZFCP on SC 5 using AI:1 QEBSM:1 PRI:1 TDD:1 SIGA: W A
[ 388.325650] scsi host0: zfcp
</code></pre>
<p>This probably happens due to a mapping issue of the zfcp devices on the s390qa102 virtual machine.<br>
A recommendation on how to proceed here is to file an infra ticket in order for the issue to be further investigated.</p>
openQA Tests - action #95926 (Resolved): [qe-core] Investigate if mau-qa_userspace_openssh covera...https://progress.opensuse.org/issues/959262021-07-23T12:44:21Zgeorggkioulis@suse.com
<p>We need to investigate whether <code>mau-qa_userspace_openssh</code> covers any functional test cases that are not covered by the other ssh tests currently scheduled (eg sshd).</p>
<p>If not, <code>mau-qa_userspace_openssh</code> should be unscheduled (and most probably completely remove it from the os-autoinst-distri-opensuse repo, if no other squad depends on it, as it looks to be the case)</p>
openQA Tests - action #95798 (Resolved): [qe-core] SLE 15-SP3 missing from version specific secti...https://progress.opensuse.org/issues/957982021-07-21T14:34:22Zgeorggkioulis@suse.com
<p>the following yamls are missing an entry for SLE 15-SP3 in the conditional_schedule/version_specific section:</p>
<ul>
<li>schedule/qam/common/mau-extratests1.yaml </li>
<li>schedule/qam/common/mau-extratests2.yaml</li>
<li>schedule/qam/common/mau-extratests-phub.yaml</li>
</ul>
<p>This results in a number of modules (osinfo_db, ovn, firewalld, libgcrypt, valgrind, journald_fss, openvswitch_ssl and others) not being run for SLE 15-SP3 in maintenance.</p>
<p>There would be need to add an entry for 15-SP3 and also check/report if there are any related failures in those modules.</p>
openQA Tests - action #90923 (Resolved): [qe-core] Schedule userspace_systemd in SLE 15 SP3https://progress.opensuse.org/issues/909232021-04-09T12:13:30Zgeorggkioulis@suse.com
<p>A <a href="https://openqa.suse.de/tests/5793735#" class="external">userspace_systemd</a> job is running on maintenance products but not on 15 SP3.</p>
<p>There already is a qa_userspace_systemd testsuite (defined but unscheduled).</p>
<p>It is needed to verify that there are no issues running it on 15 SP3.</p>
<p>After that the job can be scheduled in the Functional Job Group</p>
openQA Tests - action #89461 (Resolved): [qe-core][systemd] qa_test_systemd fails in check-mdmonitorhttps://progress.opensuse.org/issues/894612021-03-04T08:41:41Zgeorggkioulis@suse.com
<p>testcase <code>check-mdmonitor</code> of <code>qa_test_systemd</code> package fails in sle 15-SP1 and sle 15-SP2</p>
openQA Tests - action #89335 (Resolved): [qe-core][systemd] qa_test_systemd fails in check-unit t...https://progress.opensuse.org/issues/893352021-03-02T12:03:14Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-Server-DVD-Updates-x86_64-mau-qa_userspace_systemd@64bit fails in <code>check-unit</code> testcase<br>
<a href="http://angmar.suse.de/tests/3069/modules/1_systemd/steps/63" class="external">1_systemd</a></p>
<a name="More-info"></a>
<h2 >More info<a href="#More-info" class="wiki-anchor">¶</a></h2>
<p><code>check-unit</code> testcase fails both is sle-15 and sle-15-sp1 because <code>qaperf.service</code> of <code>qa_testset_automation</code> package fails to start for SLE-15 and SLE-15SP1.</p>
openQA Tests - action #88648 (Resolved): [qe-core][qem][systemd] qa_test_systemd fails in check-l...https://progress.opensuse.org/issues/886482021-02-16T13:51:51Zgeorggkioulis@suse.com
<p>The systemd testsuite (<code>qa_test_systemd</code>) fails in</p>
<ul>
<li><code>check-named</code> for sle 15, sle 15sp1 and sle 15sp2. The service <code>named.service</code> does not exist in those products.</li>
<li><code>check-lvm2-lvmetad</code> for sle 15sp2. The service <code>lvm2-lvmetad.service</code> does not exist in this product.</li>
</ul>
<p>The problem is a bit different than one might first think, because the default behavior of the testsuite should be to SKIP those missing service tests rather than fail.<br>
But how do we know what the default behavior should be?</p>
<p>To answer this, let's check sle 12sp5:<br>
In this product, the <code>named.service</code> does not exist, similar to sle 15 and above. However the <code>check-named</code> testcase is SKIPPED here.<br>
The <code>/usr/share/qa/tools/test_systemd_run</code> script (that runs the testsuite) in short runs <code>/usr/share/qa/qa_test_systemd/check-service.sh</code> against all to-be-tested services as listed in <code>/usr/share/qa/qa_test_systemd/tcf/qa_systemd.tcf</code>.<br>
<code>/usr/share/qa/qa_test_systemd/check-service.sh</code> contains a function <code>function get_loaded()</code> that gets the <code>Loaded:</code> status of the service that is being tested. Later in the code, if this status is <code>"not-found"</code>, then the script exits with <code>exit 22</code>. This results in the current service test being skipped.<br>
So for 12sp5 if we would be testing a service called <code>imaginary-service</code>, <code>get_loaded()</code> would run</p>
<pre><code> # systemctl status imaginary-service
imaginary-service.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
</code></pre>
<p>So after <code>grepping</code> the <code>Loaded</code> status (which is <code>"not-found"</code>), it would skip the test for <code>imaginary-service.service</code></p>
<p>However for sle 15 and above the output of systemctl has changed:<br>
Here we get</p>
<pre><code>systemctl status imaginary-service
Unit imaginary-service.service could not be found.
</code></pre>
<p>Which means that <code>get_loaded</code> cannot grep the <code>Loaded</code> status and exits with <code>exit 1</code>, resulting in a failing testcase.</p>
<p>Given the above, there are two potential actions to address the aforementioned fails:</p>
<ul>
<li>The testsuite behavior should be fixed for the sle 15 products, namely how the <code>get_loaded</code> function gets the loaded status.</li>
<li>I also believe (but I am not sure if it is the correct route) that apart from the above change, the tests for the services that are no longer found (<code>check-lvm2-lvmetad</code> and <code>check-named</code>) should be removed from the <code>qa_systemd.tcf</code> of the qa_test_systemd versions that correspond to those products</li>
</ul>
openQA Tests - action #78296 (Resolved): [qe-core][qem] test fails in install_updatehttps://progress.opensuse.org/issues/782962020-11-19T13:41:03Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-12-SP3-Server-DVD-Incidents-Minimal-x86_64-qam-minimal-full@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4920287/modules/install_update/steps/48" class="external">install_update</a></p>
<p>The error message is <code>nothing provides libzypp >= 16.21.2 needed by zypper-1.13.57-21.32.1.x86_64</code></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>minimal = base pattern, minimal (enhanced base) pattern are additional convenience paclkages</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/4919728" class="external">:16986:zypper</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.suse.de/tests/4915695" class="external">:16967:ca-certificates-mozilla</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=Server-DVD-Incidents-Minimal&machine=64bit&test=qam-minimal-full&version=12-SP3" class="external">latest</a></p>
openQA Tests - coordination #69055 (Resolved): [qe-core][qem][openvswitch][epic][sprint] Increase...https://progress.opensuse.org/issues/690552020-07-16T14:43:24Zgeorggkioulis@suse.com
<p>According to <a href="https://jira.suse.com/browse/ECO-2242" class="external">ECO-2242</a> Openvswitch will include some new packages in 15 SP2:<br>
Those will be:</p>
<ul>
<li>openvswitch-ipsec</li>
<li>openvswitch-pki</li>
<li>openvswitch-test</li>
<li>openvswitch-vtep</li>
</ul>
<p>Also there is a new set of ovn packages, those have been split into another ticket <a href="https://progress.opensuse.org/issues/70501" class="external">https://progress.opensuse.org/issues/70501</a>.</p>
<p>There is need to expand openvswitch testing to cover relevant usecases.<br>
Before implementation this will require some investigation on what scenarios to include.</p>
openQA Tests - action #44306 (Closed): [qam] test fails in ant due to com.sun.tools.javac.Main no...https://progress.opensuse.org/issues/443062018-11-23T16:23:39Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-12-SP3-Server-DVD-Updates-x86_64-mau-extratests@64bit fails in<br>
<a href="https://openqa.suse.de/tests/2277443/modules/ant/steps/20" class="external">ant</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/2277443" class="external">20181123-2</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/2275386" class="external">20181123-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&version=12-SP3&distri=sle&test=mau-extratests&flavor=Server-DVD-Updates&machine=64bit" class="external">latest</a></p>