openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842019-06-12T13:48:56ZopenSUSE Project Management Tool
Redmine openQA Tests - coordination #52949 (Resolved): [qe-core][RPi3][epic] SLES on RaspberryPihttps://progress.opensuse.org/issues/529492019-06-12T13:48:56Zthehejikthehejik@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We introduced openQA tests for RPi3 (using general aarch64 QEMU workers) on SLE15-SP1 product which are using only textmode "initialization" process based on jeos-firstboot services (as other JeOSes does).</p>
<p>But now we started with SLE12-SP5 which is using original SLE12 method with X11 graphical yast2-firstboot service. And of course the JeOS tests are failing in openQA then, see <a href="https://openqa.suse.de/tests/2972221" class="external">https://openqa.suse.de/tests/2972221</a></p>
<p>So basically we would need to add support for JeOS openQA tests to be able test graphical as well as textmode image initialization methods for upcoming products like SLE12-SP5 and SLE15-SP2 and up.</p>
<p>There is a small chance we will switch all upcoming SLE12 images to use the textmode jeos-firstboot but it's still not clear so please stay tuned - afaerber said on 12.06.2019: I raised the topic for the PRD but am not aware of a clarification yet.</p>
<p>Until now tests were performed manually on milestone candidates following the instructions from <a href="https://bugzilla.suse.com/tr_show_plan.cgi?plan_id=6328" class="external">https://bugzilla.suse.com/tr_show_plan.cgi?plan_id=6328</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> Automatic testing for SLES on Raspberry Pi is covered for Tumbleweed and SLE15-SP3</li>
<li><strong>AC2:</strong> Sub-Tasks are resolved</li>
</ul>
<a name="Further-information"></a>
<h2 >Further information<a href="#Further-information" class="wiki-anchor">¶</a></h2>
<ul>
<li>The disk image is generated reusing JeOS setup in OBS, so the behavior is similar: <a href="https://openqa.opensuse.org/tests/1382875" class="external">opensuse-Tumbleweed-JeOS-for-kvm-and-xen-x86_64-Build20200901-jeos@64bit_virtio</a></li>
<li>Tumbleweed on RPi: <a href="https://openqa.opensuse.org/tests/overview?distri=microos&distri=opensuse&version=Tumbleweed&build=20200825&groupid=3&flavor=JeOS-for-RPi" class="external">https://openqa.opensuse.org/tests/overview?distri=microos&distri=opensuse&version=Tumbleweed&build=20200825&groupid=3&flavor=JeOS-for-RPi</a></li>
<li>There was a previous attempt to automate testing for SLE: <a href="https://openqa.suse.de/tests/overview?arch=&machine=aarch64&modules=firstrun&groupid=162&distri=sle&build=4.131&version=12-SP5" class="external">https://openqa.suse.de/tests/overview?arch=&machine=aarch64&modules=firstrun&groupid=162&distri=sle&build=4.131&version=12-SP5</a></li>
</ul>
openQA Tests - action #37946 (Resolved): [sle][migration][sle15sp3] detect "Unknown" architecture...https://progress.opensuse.org/issues/379462018-06-27T15:12:40Zthehejikthehejik@suse.com
<p>I already filed a bug for the issue, problem is that openqa/reviewers didn't detect the issue so please add some softfail at least.</p>
<p><a href="https://bugzilla.suse.com/show_bug.cgi?id=1099325" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1099325</a></p>
<p>The issue is visible at <a href="https://openqa.suse.de/tests/1773768#step/upgrade_select/1" class="external">https://openqa.suse.de/tests/1773768#step/upgrade_select/1</a></p>
openQA Tests - action #36403 (Rejected): [caasp] test for udp flannel backendhttps://progress.opensuse.org/issues/364032018-05-22T12:55:31Zthehejikthehejik@suse.com
<p>14:39:26 - abonini: mkravec, thehejik do we have openqa tests for deploying caasp v3 with udp flannel backend?<br>
14:39:55 - mkravec: abonini: no, we use defaults for this setting<br>
14:40:17 - abonini: should we add one?<br>
14:40:36 - abonini: udp flannel backend is 100% supported not tech preview<br>
14:40:44 - abonini: talked with flavio<br>
14:43:30 - mkravec: abonini: we can add test for it<br>
14:43:58 - thehejik: abonini: creating ticket for "udp flannel backend" test<br>
14:45:38 - abonini: thehejik, mkravec cool<br>
14:47:11 - abonini: just a fyi, you need to change the port to 8285 also, it's documented in the ui in network overlay settings<br>
14:50:54 - thehejik: abonini: thanks, noted</p>
<p>I assume that configuration of this is available under "Overlay network settings" in velum before bootstrapping.</p>
<p>We should incorporate this test only for one flavor in openQA - let say that DVD will use defaults and VMX will use flannel.</p>
openQA Tests - action #34813 (Resolved): [microos] tests for caasp toolchain modulehttps://progress.opensuse.org/issues/348132018-04-12T13:18:49Zthehejikthehejik@suse.com
<p>According to PRD document for CaaSP 3.0 we should test Toolchain module/add-on in CaaSP 3.0 for kernel debugging purposes.</p>
<ul>
<li>The module will be distributed for end users as a new SCC channel for CaaSP 3 over SUSEConnect (online SCC repo only, no DVD)</li>
<li>Thorsten wants to test installing of KMP kernel modules (like Nvidia) and little debugging with strace, gdb, (tcpdump)</li>
<li>URI of the module in IBS is SUSE:Products:SUSE-CaaSP-Toolchain:3:x86_64</li>
</ul>
<p>Trello card from SCC team <a href="https://trello.com/c/LL8lkF4E/91-caasp3-toolchain-module" class="external">https://trello.com/c/LL8lkF4E/91-caasp3-toolchain-module</a> (card in current sprint so it should be ready soon)</p>
<p>The card has been marked as done today 18.4.2018.</p>
<p>We have discussed the workflow with aherzig:</p>
<ul>
<li>user will register CaaSP by using SUSEConnect -r </li>
<li>after registering there should be free toolchain extension available in SUSEConnect -l output:
AVAILABLE EXTENSIONS AND MODULES</li>
</ul>
<p>FREE EXTENSIONS</p>
<p>SUSE CaaS Plattform Toolchain 3.0 x86_64<br>
Install with: SUSEConnect -p caasp-toolchain/3.0/x86_64</p>
<p>MORE INFORMATION</p>
<p>You can find more information about available modules here:<br>
<a href="https://www.suse.com/products/server/features/modules.html" class="external">https://www.suse.com/products/server/features/modules.html</a></p>
<ul>
<li>register Toolchain module by calling SUSEConnect -p caasp-toolchain/3.0/x86_64</li>
<li>install tcpdump|gcc|gdb|strace</li>
</ul>
openQA Tests - action #33700 (Resolved): [slenkins][qam] tcpd test fails in 2_tcpdmatch - hostnam...https://progress.opensuse.org/issues/337002018-03-23T08:22:42Zthehejikthehejik@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-slenkins-twopence-tcpd-control@64bit fails in<br>
<a href="https://openqa.suse.de/tests/1566506#step/2_tcpdmatch/1" class="external">slenkins_control</a></p>
<pre><code>coolo: thehejik: https://openqa.suse.de/tests/1566506#step/2_tcpdmatch/1 - this looks like a problem with the openvswitch network. it started 2 weeks ago - but is not consistent. can you throw theories at the problem please? :)
thehejik: coolo: yes, vsvecova already reported, maybe it has something to do with https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4537 and mkravec told me that we shouldn't set fqdn hostname by hostnamectl but just hostname without domain so we need to investigate
coolo: thehejik: checking the salt commits - we did the openvswitch config 9 days before the problem started
thehejik: coolo: hopefully its not openvswitch related this time
coolo: thehejik: as our DNS setup was fixed, we should just revert these hacks
mkravec: coolo: I will do it
</code></pre>
<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/1566219" class="external">20180323-1</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/1565811" class="external">20180321-3</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?test=slenkins-twopence-tcpd-control&flavor=Server-DVD-Updates&machine=64bit&arch=x86_64&version=12-SP3&distri=sle" class="external">latest</a></p>
openQA Infrastructure - action #33253 (Resolved): [salt] add support for multiple multi-host work...https://progress.opensuse.org/issues/332532018-03-14T10:02:33Zthehejikthehejik@suse.com
<p>Currently we have support only for one multihost WORKER_CLASS="tap" but we would need to create different multi-host cluster for WORKER_CLASS="caasp_x86_64" ideally separated from the "tap" cluster. Later we would need probably even more for aarch64 and so.</p>
<p>Changes should be incorporated into <a href="https://gitlab.suse.de/openqa/salt-states-openqa/blob/master/openqa/openvswitch.sls" class="external">https://gitlab.suse.de/openqa/salt-states-openqa/blob/master/openqa/openvswitch.sls</a></p>
openQA Tests - action #32338 (Resolved): [aarch64]Prepare support_server image based on SLE12SP3 ...https://progress.opensuse.org/issues/323382018-02-27T08:47:49Zthehejikthehejik@suse.com
<p>Yesterday we enabled multimachine worker setup for aarch64 (openqaworker-arm-{1..3} - openqaworker-arm-2 has "tap" WORKER_CLASS already configured), it would be nice to have support_server image for aarch64 based on SLE12SP3.</p>
openQA Infrastructure - action #32314 (Resolved): [salt] make GRE tunnels salt-states compatible ...https://progress.opensuse.org/issues/323142018-02-26T16:22:57Zthehejikthehejik@suse.com
<p>Problem is that in past we had for every worker instance (instance of worker on worker host) defined its own WORKER_CLASS in form:<br>
<code>1: <br>
WORKER_CLASS: something<br>
2:<br>
WORKER_CLASS: something_else</code></p>
<p>but now we have Global settings (aarch64) valid for every worker instance (amount defined by numofworkers: 20)<br>
<code>numofworkers: 20<br>
global:<br>
WORKER_CLASS: qemu_aarch64,qemu_aarch64_slow_worker</code></p>
<p>Btw we should also restart wickedd service when the initial mm ovs setup is done to get it working (see poo#32296)</p>
openQA Tests - action #32107 (Resolved): [sle][functional][workable] let support_server wait for ...https://progress.opensuse.org/issues/321072018-02-21T13:14:42Zthehejikthehejik@suse.com
<p>Currently the support_server VM and its DHCP service doesn't wait for initial bootup of remote VM when the installation is done and then the remote VM doesn't have any IPv4 address.</p>
<p>Fix already done <a href="https://github.com/thehejik/os-autoinst-distri-opensuse/commit/e22f8303936ba81bd3e3bf038cb15c9d5976b63f" class="external">https://github.com/thehejik/os-autoinst-distri-opensuse/commit/e22f8303936ba81bd3e3bf038cb15c9d5976b63f</a></p>
<p>Before: <a href="https://openqa.suse.de/tests/1487230#step/remote_target/3" class="external">https://openqa.suse.de/tests/1487230#step/remote_target/3</a> - note there is no ipv4 address for eth0 adaptor.<br>
After: <a href="http://dhcp195.suse.cz/tests/594#step/remote_target/3" class="external">http://dhcp195.suse.cz/tests/594#step/remote_target/3</a></p>
openQA Tests - action #25754 (Resolved): [sle][functional][yast][easy] don't wait 100s for pop-up...https://progress.opensuse.org/issues/257542017-10-04T08:20:09Zthehejikthehejik@suse.com
<p>In addon_installation_yast2.pm we have following code which means that we are waiting 100s for pop-up which will not occur is most cases.</p>
<p><code>if (check_screen 'addon-installation-pop-up', 100) { # e.g. RT reboot to activate new kernel<br>
...<br>
}<br>
</code></p>
<p>Rodion wrote following:<br>
I know that this code was here before, but it's bad that we will wait for 100 seconds when pop up is not there. So maybe we can improve here and do assert_screen on multiple tags and process them accordingly using match_has_tag api call.</p>
<p>Note: this is old ticket, I was not able to find any test suite which uses this module.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<p><strong>AC1:</strong> There is no check screen with 100 seconds, replaced with multi tag match instead</p>
<p><a href="https://openqa.suse.de/tests/1378824" class="external">https://openqa.suse.de/tests/1378824</a> (won't be triggered until next RT release which is not yet scheduled).</p>
openQA Project - action #20920 (Resolved): [tools] Try out if we can connect more than 2 ovs brid...https://progress.opensuse.org/issues/209202017-07-28T14:41:32Zthehejikthehejik@suse.com
<p>Coolo wants spread a load for slenkins/autoyast tests on all multi-machine workers because w3 is pretty overloaded and w8+w9 (now dedicated for caasp) are idle.</p>
<p>w8 and w9 are connected already over GRE but we will need to try out if we can connect w8+w9 with w3 at the same time. Then we can use same WORKER_CLASS=tap on those workers.</p>
openQA Project - action #20002 (Resolved): [tools] openqa sometimes doesn't update job_dependenci...https://progress.opensuse.org/issues/200022017-06-22T14:28:02Zthehejikthehejik@suse.com
<p>For multi-machine jobs (caasp and slenkins) openQA time to time doesn't schedule all child jobs by triggering its parent CaaSP-controller or slenkins-<em>-control job.<br>
It seems that not all child jobs are running because **there are missing entries for that jobs in job_dependencies SQL table</em>*.</p>
<p>Example of broken job <a href="https://openqa.suse.de/tests/1016423" class="external">https://openqa.suse.de/tests/1016423</a> CaaSP-controller (In this case we miss admin node so then the whole test failed)</p>
<pre><code>`# select count(child_job_id) from job_dependencies where parent_job_id=1016423;
count
-------
22
(1 row)`
</code></pre>
<p>If you try examine some successful CaaSP-controller job (eg. id=1015418) you should get count=25 (1x controller, 1x admin, 1x master, 22x workers).</p>
<p>I'm not able to reproduce the issue on request but the problem sometimes occurs in my local openqa instance using sqlite and also o.s.d using postgresql. The broken job dependency could be solved by posting iso again.</p>
<p>Maybe it has something to do with scheduler which just skips some db insert queries. </p>
<p>I'm sorry being so brief but I really don't know more.</p>
openQA Tests - action #19614 (Resolved): [tests][slenkins] change prio for SRPMS repo in shim tes...https://progress.opensuse.org/issues/196142017-06-06T12:48:15Zthehejikthehejik@suse.com
<p>Problem is that in openqa the DVD repo is enabled and it has same priority as SRPMS repository. Then shim testsuite is trying to install shim.srpm from DVD#2 which is not available nor mounted instead of online SRPMS repo.</p>
<p><a href="https://openqa.suse.de/tests/964538#step/1_shim_suite/3" class="external">https://openqa.suse.de/tests/964538#step/1_shim_suite/3</a></p>
<p>susetest:~ # zypper lr -d<br>
Repository priorities are without effect. All enabled repositories share the same priority.</p>
<table><thead>
<tr>
<th>#</th>
<th>Alias</th>
<th>Name</th>
<th>Enabled</th>
<th>GPG Check</th>
<th>Refresh</th>
<th>Priority</th>
<th>Type</th>
<th>URI</th>
<th>Service</th>
</tr>
</thead><tbody>
<tr>
<td>1</td>
<td>SDK12-SP3_12.3-0</td>
<td>SDK12-SP3 12.3-0</td>
<td>Yes</td>
<td>(r ) Yes</td>
<td>No</td>
<td>99</td>
<td>yast2</td>
<td>dvd:///?devices=/dev/sr1</td>
<td></td>
</tr>
<tr>
<td>2</td>
<td>SLES12-SP3-12.3-0</td>
<td>SLES12-SP3-12.3-0</td>
<td>Yes</td>
<td>(r ) Yes</td>
<td>No</td>
<td>99</td>
<td>yast2</td>
<td>cd:///?devices=/dev/disk/by-id/scsi-0QEMU_QEMU_CD-ROM_cd0</td>
<td></td>
</tr>
</tbody></table>
<p>The solution should be rise the priority of SRPMS repo to 50 (smaller number ~ higher priority)</p>
openQA Tests - action #18444 (Resolved): [sles][functional]Make partitioning_raid test compatible...https://progress.opensuse.org/issues/184442017-04-07T14:57:02Zthehejikthehejik@suse.com
<p>Was created mainly due failing RAID tests on aarch64, see <a href="https://bugzilla.suse.com/show_bug.cgi?id=1032058" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1032058</a> </p>
<p>The problem is that ESP partition /boot/efi is created on RAID1 volume which is not supported by UEFI - EFI is compatible only with MBR/GPT tables with FAT partition and cannot read mdadm magic superblocks. So the machine is not able to boot after installation.</p>
<p><a href="https://openqa.suse.de/tests/855025#step/grub_test/5" class="external">https://openqa.suse.de/tests/855025#step/grub_test/5</a></p>
openQA Project - action #18082 (Resolved): [tools][dashboard]Sort by time within parent group ove...https://progress.opensuse.org/issues/180822017-03-28T09:33:35Zthehejikthehejik@suse.com
<p>It would be nice if we can sort the builds/results by time and not by build nrs only in parent groups (as I know it should be possible in subgroups already).</p>
<p>In CaaSP we have different numbering for each target platform (xen/kvm/vmware...) and the overview page is a bit cluttering.</p>
<p><a href="https://openqa.suse.de/parent_group_overview/11" class="external">https://openqa.suse.de/parent_group_overview/11</a></p>