openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-02-27T17:27:27ZopenSUSE Project Management Tool
Redmine openQA Project - action #156169 (New): Automatically validate ay-openqa-worker.xml.erbhttps://progress.opensuse.org/issues/1561692024-02-27T17:27:27Zybonatakisioannis.bonatakis@suse.com
<p><a href="https://github.com/os-autoinst/openQA/blob/master/contrib/ay-openqa-worker.xml.erb" class="external">https://github.com/os-autoinst/openQA/blob/master/contrib/ay-openqa-worker.xml.erb</a> is used for openqa workers. <br>
This is passed as-is to the autoyast and seems to work.<br>
But when generate the xml manual</p>
<ul>
<li>Either TW or Leap</li>
<li>install autoyast2</li>
<li>Run <code>sudo yast2 autoyast check-profile filename=ay-openqa-worker.xml.erb output=result.xml run-scripts=true run-erb=true</code></li>
</ul>
<p>Then complains for:</p>
<ul>
<li>firewall configuration</li>
<li>failure to run the scripts</li>
</ul>
<p>I am not sure about the requirements about the later, but firewall should be easy to address.</p>
openQA Tests - action #135218 (In Progress): test regression in ww4_await_pxe_installhttps://progress.opensuse.org/issues/1352182023-09-06T06:44:43Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Tries to boot before the server gets ready and process fails.</p>
<p>openQA test in scenario sle-15-SP6-Online-x86_64-hpc_ww4_compute0@64bit fails in<br>
<a href="https://openqa.suse.de/tests/12014546/modules/ww4_await_pxe_install/steps/7" class="external">ww4_await_pxe_install</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>first compute node for warewulf booting from network (PXE) after the controller is ready for connection.</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/11979509" class="external">16.1</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=Online&machine=64bit&test=hpc_ww4_compute0&version=15-SP6" class="external">latest</a></p>
openQA Tests - action #128594 (New): test fails in spack_masterhttps://progress.opensuse.org/issues/1285942023-05-03T12:50:53Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>This is related to LD_LIBRARY_PATH again similar to bsc#1208751 [1].</p>
<p>To solve the problem back then, we replace the source file which we compile and run with a simple one which it doesnt have dependency on boost library.<br>
As such we had only to load mpich. SLE15SP5 seems with this. However the SLE15SP3 doesnt accept this change. <br>
The spack versions are quite the same<br>
SLE15SP3 -> 0.19.1-150300.5.16.1<br>
SLE15SP5 -> 0.19.1-150400.12.5.1</p>
<p>The thing is that despite the source file nothing else has change. the test fails in the same version which is used by previous jobs.</p>
<p>[1] <a href="https://bugzilla.suse.com/show_bug.cgi?id=1208751" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1208751</a></p>
<p>openQA test in scenario sle-15-SP3-Server-DVD-HPC-Incidents-x86_64-hpc_BETA_mpich_spack_master@64bit-4gbram fails in<br>
<a href="https://openqa.suse.de/tests/11015548/modules/spack_master/steps/118" class="external">spack_master</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Basic tests of mpich with CPU count=2. </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/10938144" class="external">:28369:hdf5</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/10882077" class="external">:28369:hdf5</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-HPC-Incidents&machine=64bit-4gbram&test=hpc_BETA_mpich_spack_master&version=15-SP3" class="external">latest</a></p>
openQA Project - action #126032 (Resolved): iso posts do not start all the children chainhttps://progress.opensuse.org/issues/1260322023-03-15T04:34:31Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Not all the child jobs are scheduled from the parent.</p>
<p>I noticed that in the last two build IIRC. For some reason that occurred in this specific test.<br>
The rest of the multijobs looks to start as expected.<br>
However a few examples i tried out reproduce the problem. </p>
<p><a href="#" onclick="$('#collapse-69984729-show, #collapse-69984729-hide').toggle(); $('#collapse-69984729').fadeToggle(150);; return false;" id="collapse-69984729-show" class="icon icon-collapsed collapsible">iso posts example with _SKIP_CHAINED_DEPS</a><a href="#" onclick="$('#collapse-69984729-show, #collapse-69984729-hide').toggle(); $('#collapse-69984729').fadeToggle(150);; return false;" id="collapse-69984729-hide" class="icon icon-expanded collapsible" style="display:none;">iso posts example with _SKIP_CHAINED_DEPS</a><div id="collapse-69984729" class="collapsed-text" style="display:none;"><p>openqa-cli api --pretty --osd -X POST isos ISO=SLE-15-SP5-Online-aarch64-Build80.1-Media1.iso DISTRI=sle VERSION=15-SP5 FLAVOR=Online ARCH=aarch64 BUILD=80.1 TEST=hpc_BETA_mpich_mpi_supportserver _GRPOUP_ID=130<br>
{<br>
"count" : 2,<br>
"failed" : [],<br>
"ids" : [<br>
10698182,<br>
10698183<br>
],<br>
"scheduled_product_id" : 1768408<br>
}</p>
</div></p>
<p><a href="#" onclick="$('#collapse-2255f8df-show, #collapse-2255f8df-hide').toggle(); $('#collapse-2255f8df').fadeToggle(150);; return false;" id="collapse-2255f8df-show" class="icon icon-collapsed collapsible">iso posts example with _SKIP_CHAINED_DEPS</a><a href="#" onclick="$('#collapse-2255f8df-show, #collapse-2255f8df-hide').toggle(); $('#collapse-2255f8df').fadeToggle(150);; return false;" id="collapse-2255f8df-hide" class="icon icon-expanded collapsible" style="display:none;">iso posts example with _SKIP_CHAINED_DEPS</a><div id="collapse-2255f8df" class="collapsed-text" style="display:none;"><p>openqa-cli api --pretty --osd -X POST isos ISO=SLE-15-SP5-Online-aarch64-Build80.1-Media1.iso DISTRI=sle VERSION=15-SP5 FLAVOR=Online ARCH=aarch64 BUILD=80.1 TEST=hpc_BETA_mvapich2_mpi_supportserver _GRPOUP_ID=130 _SKIP_CHAINED_DEPS=1<br>
{<br>
"count" : 1,<br>
"failed" : [],<br>
"ids" : [<br>
10698186<br>
],<br>
"scheduled_product_id" : 1768410</p>
</div></p>
<p>All children has <code>PARALLEL_WITH=hpc_BETA_mpich_mpi_supportserver</code> on Test Suites</p>
<p>openQA test in scenario sle-15-SP5-Online-x86_64-hpc_BETA_mpich_mpi_supportserver@64bit fails in<br>
<a href="https://openqa.suse.de/tests/10691528/modules/wait_children/steps/7" class="external">wait_children</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Basic tests of mpich with CPU count=2. Maintainer: schlad <a href="mailto:schlad@suse.de">schlad@suse.de</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/10691528" class="external">80.1</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p><a href="#" onclick="$('#collapse-f99ef044-show, #collapse-f99ef044-hide').toggle(); $('#collapse-f99ef044').fadeToggle(150);; return false;" id="collapse-f99ef044-show" class="icon icon-collapsed collapsible">should look like</a><a href="#" onclick="$('#collapse-f99ef044-show, #collapse-f99ef044-hide').toggle(); $('#collapse-f99ef044').fadeToggle(150);; return false;" id="collapse-f99ef044-hide" class="icon icon-expanded collapsible" style="display:none;">should look like</a><div id="collapse-f99ef044" class="collapsed-text" style="display:none;"><p>openqa-cli api --pretty --osd -X POST isos ISO=SLE-15-SP5-Online-x86_64-Build80.1-Media1.iso DISTRI=sle VERSION=15-SP5 FLAVOR=Online ARCH=x86_64 BUILD=80.1 TEST=hpc_BETA_mpich_mpi_supportserver,hpc_BETA_mpich_mpi_slave01,hpc_BETA_mpich_mpi_slave00,hpc_BETA_mpich_mpi_master _GRPOUP_ID=130 _SKIP_CHAINED_DEPS=1<br>
{<br>
"count" : 4,<br>
"failed" : [],<br>
"ids" : [<br>
10698191,<br>
10698192,<br>
10698193,<br>
10698194<br>
],<br>
"scheduled_product_id" : 1768412<br>
}</p>
</div><br>
Last good: <a href="https://openqa.suse.de/tests/10687724" class="external">80.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=Online&machine=64bit&test=hpc_BETA_mpich_mpi_supportserver&version=15-SP5" class="external">latest</a></p>
openQA Tests - action #120900 (New): Required patterns values are not removed on select_patterns https://progress.opensuse.org/issues/1209002022-11-23T17:38:39Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>I am not sure if the title is accurate. What actually happens can be seen on the attached screen <a href="https://openqa.suse.de/tests/9825401/modules/select_patterns/steps/124" class="external">select_patterns</a><br>
The specific job set <code>PATTERNS": "base,minimal,apparmor"</code> but at the end only minimal and apparmor are selected. The problem is that another pattern is deselected after the base is checked.<br>
Due to the logic of the <code>select_specific_patterns_by_iteration</code> function, which iterates from top to bottom, it can happen a previous pattern to alter as a dependency of another selection/deselection on a later checkbox.</p>
<p>Also i found the code a bit complicated. For starters there is two different approaches to uncheck patterns</p>
<ol>
<li><code>$self->deselect_pattern() if get_var('EXCLUDE_PATTERNS');</code></li>
<li>inside <code>select_specific_patterns_by_iteration</code> using minus notation on PATTERNS.</li>
</ol>
<p>I think this is unnecessarily complexity<br>
Also i believe that the <code>process_patterns</code> should take care and acts of <em>defaults</em> PATTERNS. As now the logic is inside <code>select_specific_patterns_by_iteration</code></p>
<p>This ticket to improve and improve in all the above. I dont think this is high priority -nor even normal- as it doesnt have destructive impact on the most of the test cases but hides <strong>a seriously defect which produces an unexpected installation than the one was set it up for</strong>.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>To reproduce you can set <code>PATTERNS": "base,minimal,apparmor"</code> and choose a job which by default has <code>GNOME</code> checked. At the end of the <code>select_specific_patterns_by_iteration</code> review the <em>installation settings</em> window before the installation</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>PATTERNS values are ensured are selected at the end of the <code>process_patterns</code></p>
openQA Tests - action #118663 (New): [qe-core] wait_serial reports fail on serial_terminal when i...https://progress.opensuse.org/issues/1186632022-10-13T13:38:34Zybonatakisioannis.bonatakis@suse.com
<a name="Description"></a>
<h1 >Description<a href="#Description" class="wiki-anchor">¶</a></h1>
<p>The problem appears in a scenario where you run a container and launch its interactive console and the module itself uses serial_terminal</p>
<p><a href="#" onclick="$('#collapse-2a1aa7fa-show, #collapse-2a1aa7fa-hide').toggle(); $('#collapse-2a1aa7fa').fadeToggle(150);; return false;" id="collapse-2a1aa7fa-show" class="icon icon-collapsed collapsible">autoinst-log.txt...</a><a href="#" onclick="$('#collapse-2a1aa7fa-show, #collapse-2a1aa7fa-hide').toggle(); $('#collapse-2a1aa7fa').fadeToggle(150);; return false;" id="collapse-2a1aa7fa-hide" class="icon icon-expanded collapsible" style="display:none;">autoinst-log.txt...</a><div id="collapse-2a1aa7fa" class="collapsed-text" style="display:none;"><pre><code>[2022-10-13T15:17:01.951831+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:17:01.952227+02:00] [debug] <<< testapi::wait_serial(timeout=90, buffer_size=undef, no_regex=1, expect_not_found=0, regexp="# ", quiet=1, record_output=undef)
[2022-10-13T15:17:01.953435+02:00] [debug] <<< consoles::serial_screen::read_until(timeout=90, no_regex=1, record_output=undef, buffer_size=undef, pattern=[
"# "
], regexp="# ", expect_not_found=0, quiet=1, json_cmd_token="stLkEWrr", cmd="backend_wait_serial")
[2022-10-13T15:18:32.041417+02:00] [debug] >>> testapi::wait_serial: # : fail
[2022-10-13T15:18:32.041731+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:18:32.041945+02:00] [debug] <<< distribution::script_output("Content of /tmp/script_uow4.sh :\n \"cat > /tmp/script_uow4.sh << 'EOT__uow4'; echo _uow4-\$?-\" \n")
[2022-10-13T15:18:32.043257+02:00] [debug] <<< consoles::serial_screen::type_string(text="cat > /tmp/script_uow4.sh << 'EOT__uow4'; echo _uow4-\$?-\n", json_cmd_token="kCaIjsnI", cmd="backend_type_string")
[2022-10-13T15:18:32.044126+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:18:32.044536+02:00] [debug] <<< testapi::wait_serial(quiet=1, record_output=undef, timeout=90, buffer_size=undef, expect_not_found=0, regexp="cat > /tmp/script_uow4.sh << 'EOT__uow4'; echo _uow4-\$?-", no_regex=1)
[2022-10-13T15:18:32.045981+02:00] [debug] <<< consoles::serial_screen::read_until(record_output=undef, timeout=90, no_regex=1, quiet=1, json_cmd_token="KTIlmTxF", cmd="backend_wait_serial", pattern=[
"cat > /tmp/script_uow4.sh << 'EOT__uow4'; echo _uow4-\$?-"
], buffer_size=undef, regexp="cat > /tmp/script_uow4.sh << 'EOT__uow4'; echo _uow4-\$?-", expect_not_found=0)
[2022-10-13T15:18:32.046286+02:00] [info] ::: consoles::serial_screen::read_until: Matched output from SUT in 2 loops & 0.000667732208967209 seconds: cat > /tmp/script_uow4.sh << 'EOT__uow4'; echo _uow4-$?-
[2022-10-13T15:18:32.047033+02:00] [debug] >>> testapi::wait_serial: cat > /tmp/script_uow4.sh << 'EOT__uow4'; echo _uow4-$?-: ok
[2022-10-13T15:18:32.047315+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:18:32.047697+02:00] [debug] <<< testapi::wait_serial(record_output=undef, quiet=1, no_regex=1, expect_not_found=0, regexp="> ", buffer_size=undef, timeout=90)
[2022-10-13T15:18:32.049043+02:00] [debug] <<< consoles::serial_screen::read_until(no_regex=1, timeout=90, record_output=undef, expect_not_found=0, regexp="> ", buffer_size=undef, pattern=[
"> "
], cmd="backend_wait_serial", json_cmd_token="TLLLRDQk", quiet=1)
[2022-10-13T15:18:32.049266+02:00] [info] ::: consoles::serial_screen::read_until: Matched output from SUT in 1 loops & 0.000562381930649281 seconds: >
[2022-10-13T15:18:32.049970+02:00] [debug] >>> testapi::wait_serial: > : ok
[2022-10-13T15:18:32.050915+02:00] [debug] <<< consoles::serial_screen::type_string(text="cat /etc/os-release && echo testdone\nEOT__uow4\n", cmd="backend_type_string", json_cmd_token="KTMInCwi")
[2022-10-13T15:18:32.051701+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:18:32.052216+02:00] [debug] <<< testapi::wait_serial(regexp="> EOT__uow4", expect_not_found=0, no_regex=1, timeout=90, buffer_size=undef, record_output=undef, quiet=1)
[2022-10-13T15:18:32.053458+02:00] [debug] <<< consoles::serial_screen::read_until(json_cmd_token="azrXZuje", cmd="backend_wait_serial", quiet=1, expect_not_found=0, regexp="> EOT__uow4", pattern=[
"> EOT__uow4"
], buffer_size=undef, record_output=undef, no_regex=1, timeout=90)
[2022-10-13T15:18:32.053728+02:00] [info] ::: consoles::serial_screen::read_until: Matched output from SUT in 2 loops & 0.000609030947089195 seconds: > EOT__uow4
[2022-10-13T15:18:32.054428+02:00] [debug] >>> testapi::wait_serial: > EOT__uow4: ok
[2022-10-13T15:18:32.054704+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:18:32.055060+02:00] [debug] <<< testapi::wait_serial(record_output=undef, quiet=1, no_regex=0, regexp="_uow4-0-", expect_not_found=0, buffer_size=undef, timeout=90)
[2022-10-13T15:18:32.056388+02:00] [debug] <<< consoles::serial_screen::read_until(timeout=90, no_regex=0, record_output=undef, pattern="_uow4-0-", buffer_size=undef, regexp="_uow4-0-", expect_not_found=0, quiet=1, cmd="backend_wait_serial", json_cmd_token="aCMENdVw")
[2022-10-13T15:18:32.058856+02:00] [info] ::: consoles::serial_screen::read_until: Matched output from SUT in 2 loops & 0.00273504760116339 seconds: _uow4-0-
[2022-10-13T15:18:32.059562+02:00] [debug] >>> testapi::wait_serial: _uow4-0-: ok
[2022-10-13T15:18:32.059848+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:18:32.060210+02:00] [debug] <<< testapi::wait_serial(expect_not_found=0, regexp="# ", no_regex=1, buffer_size=undef, timeout=90, record_output=undef, quiet=1)
[2022-10-13T15:18:32.061421+02:00] [debug] <<< consoles::serial_screen::read_until(buffer_size=undef, pattern=[
"# "
], regexp="# ", expect_not_found=0, quiet=1, cmd="backend_wait_serial", json_cmd_token="HkXhwxdk", timeout=90, no_regex=1, record_output=undef)
[2022-10-13T15:20:02.113308+02:00] [debug] >>> testapi::wait_serial: # : fail
[2022-10-13T15:20:02.114530+02:00] [debug] <<< consoles::serial_screen::type_string(json_cmd_token="ZmelFHja", cmd="backend_type_string", text="echo _uow4; bash -oe pipefail /tmp/script_uow4.sh ; echo SCRIPT_FINISHED_uow4-\$?-\n")
[2022-10-13T15:20:02.115298+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:20:02.115764+02:00] [debug] <<< testapi::wait_serial(record_output=undef, quiet=1, no_regex=1, expect_not_found=0, regexp="echo _uow4; bash -oe pipefail /tmp/script_uow4.sh ; echo SCRIPT_FINISHED_uow4-\$?-", buffer_size=undef, timeout=90)
[2022-10-13T15:20:02.117013+02:00] [debug] <<< consoles::serial_screen::read_until(buffer_size=undef, pattern=[
"echo _uow4; bash -oe pipefail /tmp/script_uow4.sh ; echo SCRIPT_FINISHED_uow4-\$?-"
], expect_not_found=0, regexp="echo _uow4; bash -oe pipefail /tmp/script_uow4.sh ; echo SCRIPT_FINISHED_uow4-\$?-", quiet=1, cmd="backend_wait_serial", json_cmd_token="HGtqBdRI", timeout=90, no_regex=1, record_output=undef)
[2022-10-13T15:20:02.117351+02:00] [info] ::: consoles::serial_screen::read_until: Matched output from SUT in 2 loops & 0.00069341529160738 seconds: echo _uow4; bash -oe pipefail /tmp/script_uow4.sh ; echo SCRIPT_FINISHED_uow4-$?-
[2022-10-13T15:20:02.118108+02:00] [debug] >>> testapi::wait_serial: echo _uow4; bash -oe pipefail /tmp/script_uow4.sh ; echo SCRIPT_FINISHED_uow4-$?-: ok
[2022-10-13T15:20:02.118391+02:00] [debug] tests/containers/apptainer.pm:50 called testapi::validate_script_output
[2022-10-13T15:20:02.118743+02:00] [debug] <<< testapi::wait_serial(expect_not_found=0, regexp="SCRIPT_FINISHED_uow4-\\d+-", no_regex=0, buffer_size=undef, timeout=90, record_output=1, quiet=1)
[2022-10-13T15:20:02.120085+02:00] [debug] <<< consoles::serial_screen::read_until(no_regex=0, timeout=90, record_output=1, expect_not_found=0, regexp="SCRIPT_FINISHED_uow4-\\d+-", buffer_size=undef, pattern="SCRIPT_FINISHED_uow4-\\d+-", cmd="backend_wait_serial", json_cmd_token="uwWUVyYC", quiet=1)
[2022-10-13T15:20:02.125432+02:00] [info] ::: consoles::serial_screen::read_until: Matched output from SUT in 8 loops & 0.00561576243489981 seconds: SCRIPT_FINISHED_uow4-0-
[2022-10-13T15:20:02.126191+02:00] [debug] >>> testapi::wait_serial: SCRIPT_FINISHED_uow4-\d+-: ok
</code></pre></div></p>
<p>I tried to play with <code>set_serial_prompt</code> and <code>set_standard_prompt</code> functions without actual solve the problem.<br>
This isnt shown up when <code>select_console</code> is used</p>
<p>The failure comes from (script_output of distribution.pm)</p>
<pre><code>testapi::wait_serial($self->{serial_term_prompt}, no_regex => 1, quiet => $args{quiet});
</code></pre>
<p>Expected:<br>
wait_serial returns <em>ok</em> or ignore <code>testapi::wait_serial</code> if is an interactive terminal</p>
<p>Additional:<br>
I think that this is low priority because doesnt make test fail or anything, but it would be nice to fix it and improve the code as it causes some additional time of the test execution without any good reason</p>
openQA Project - action #109292 (Resolved): OSD is missing x86_64 jobs duplicate key value violat...https://progress.opensuse.org/issues/1092922022-03-31T07:57:01Zybonatakisioannis.bonatakis@suse.com
<p>With the last two (117.1,118.3) or three builds x86_64 jobs are missing.</p>
<p>The very first time there was a dependency circle issue with one of the job group yaml. That found to prevent the scheduling. However the jobs are keep missing even after the correction and the scheduling looks to work without problem after manual intervention.</p>
openQA Project - action #107878 (Resolved): number of failed job provides wrong value on the buil...https://progress.opensuse.org/issues/1078782022-03-04T11:13:23Zybonatakisioannis.bonatakis@suse.com
<p><a href="https://openqa.suse.de/group_overview/130" class="external">https://openqa.suse.de/group_overview/130</a> display 2 failed jobs for build101.1.</p>
<p>if you press on the failed area of the bar, the <code>Test result overview</code> shows only one failed job. Cleaning all the filters i see that the only other job which was not successful is one failed as <code>timeout_exceeded</code>. </p>
<p>So either the <u>failed area</u> should enabled the <code>Timeout exceeded</code>(or any other flag) or it bar should point out only the actual failed jobs.</p>
openQA Tests - action #107395 (Resolved): [HPC] zypper returns error code 107 in slurm_masterhttps://progress.opensuse.org/issues/1073952022-02-23T19:04:58Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<pre><code>(4/6) Installing: twopence-0.4.2-3.d_t.22.x86_64 [.
warning: /var/cache/zypp/packages/devel_tools/x86_64/twopence-0.4.2-3.d_t.22.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 498d5a23: NOKEY
.....
/usr/lib/tmpfiles.d/net-snmp.conf:1: Line references path below legacy directory /var/run/, updating /var/run/net-snmp → /run/net-snmp; please update the tmpfiles.d/ drop-in file accordingly.
/usr/lib/tmpfiles.d/systemd.conf:19: Failed to resolve user 'systemd-network': No such process
/usr/lib/tmpfiles.d/systemd.conf:20: Failed to resolve user 'systemd-network': No such process
/usr/lib/tmpfiles.d/systemd.conf:21: Failed to resolve user 'systemd-network': No such process
/usr/lib/tmpfiles.d/systemd.conf:22: Failed to resolve user 'systemd-network': No such process
warning: %post(twopence-0.4.2-3.d_t.22.x86_64) scriptlet failed, exit status 65
done]
(5/6) Installing: libtwopence0-0.4.2-3.d_t.22.x86_64 [.
warning: /var/cache/zypp/packages/devel_tools/x86_64/libtwopence0-0.4.2-3.d_t.22.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 498d5a23: NOKEY
......done]
(6/6) Installing: twopence-shell-client-0.4.2-3.d_t.22.x86_64 [.
warning: /var/cache/zypp/packages/devel_tools/x86_64/twopence-shell-client-0.4.2-3.d_t.22.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 498d5a23: NOKEY
.......done]
n3BEE-107-
</code></pre>
<p>107 - ZYPPER_EXIT_INF_RPM_SCRIPT_FAILED means "Installation basically succeeded, but some of the packages %post install scripts returned an error"</p>
<p>openQA test in scenario sle-15-SP4-Online-x86_64-hpc_EPSILON_slurm_master@64bit fails in<br>
<a href="https://openqa.suse.de/tests/8218862/modules/slurm_master/steps/162" class="external">slurm_master</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>HPC cluster for experimental and fast-moving external tests. maintainer: <a href="mailto:schlad@suse.de">schlad@suse.de</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/8205633" class="external">99.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/8181333" class="external">98.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=Online&machine=64bit&test=hpc_EPSILON_slurm_master&version=15-SP4" class="external">latest</a></p>
openQA Project - action #98577 (Resolved): Unknown ARRAY( variables matching HDD_1 or ISO in job ...https://progress.opensuse.org/issues/985772021-09-14T07:08:55Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<ul>
<li>For instance <a href="https://openqa.suse.de/tests/7092033/file/vars.json" class="external">https://openqa.suse.de/tests/7092033/file/vars.json</a> has <code>"ARRAY(0x55bb116ac3a0)" : "SLE-15-SP3-Full-x86_64-GM-Media1.iso"</code> which is repeated and assigned correctly on <code>ISO</code>.</li>
<li>Another one on publiccloud <a href="https://openqa.suse.de/tests/7096497/file/vars.json" class="external">https://openqa.suse.de/tests/7096497/file/vars.json</a> has <code>"ARRAY(0x55b5694714b8)" : "publiccloud_15sp3_Azure_BYOS_Updates.qcow2"</code> which is what <code>HDD_1</code> represents.</li>
</ul>
<p>i havent noticed any destruction or impact on the test so far but i havent also found where this comes from.</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1</strong>: No variables based on stringified array types present in job settings</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Add unit test validating variable names (assuming this is a bug in openQA or os-autoinst)</li>
<li>Mark jobs with variable names containing <code>(</code> as incomplete (assuming this is a bug in another tool)</li>
</ul>
openQA Project - action #98388 (Resolved): Non-existing asset "uefi-vars" is still shown up on #d...https://progress.opensuse.org/issues/983882021-09-09T09:38:23Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>An example is <a href="https://openqa.suse.de/tests/6994628#downloads" class="external">https://openqa.suse.de/tests/6994628#downloads</a></p>
<p>When i clone the job it fails with</p>
<pre><code>downloading
http://openqa.suse.de/tests/6994628/asset/other/SLE-15-SP4-Online-x86_64-Build31.2-Media1.iso.sha256
to
/var/lib/openqa/factory/other/SLE-15-SP4-Online-x86_64-Build31.2-Media1.iso.sha256
downloading
http://openqa.suse.de/tests/6994628/asset/iso/SLE-15-SP4-Online-x86_64-Build31.2-Media1.iso
to
/var/lib/openqa/factory/iso/SLE-15-SP4-Online-x86_64-Build31.2-Media1.iso
downloading
http://openqa.suse.de/tests/6994628/asset/hdd/SLES-15-SP4-x86_64-Build31.2-containers.qcow2
to
/var/lib/openqa/factory/hdd/SLES-15-SP4-x86_64-Build31.2-containers.qcow2
downloading
http://openqa.suse.de/tests/6994628/asset/hdd/SLES-15-SP4-x86_64-Build31.2-containers-uefi-vars.qcow2
to
/var/lib/openqa/factory/hdd/SLES-15-SP4-x86_64-Build31.2-containers-uefi-vars.qcow2
6994628 failed: 404 Not Found
</code></pre>
<p><a href="https://openqa.suse.de/tests/6994628/asset/hdd/SLES-15-SP4-x86_64-Build31.2-containers-uefi-vars.qcow2" class="external">uefi-vars qcow2</a> seems that it is not available any more and if you try to get this file you get 404.</p>
<p>Expected:</p>
<ul>
<li>ui should not show non-available assets</li>
</ul>
<a name="Steps-to-reproduce"></a>
<h2 >Steps to reproduce<a href="#Steps-to-reproduce" class="wiki-anchor">¶</a></h2>
<p>Clone the job in the description, it returns a 404 error for an asset still shown in the UI page</p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Investigate why is it still shown in the UI page if the cleanup removes it</li>
<li>Investigate why this is removed (if it is from the cleanup script) but not the rest</li>
<li>Fix UI so that it doesn't show non-available assets</li>
<li>(optional) i wonder if the cleanup can be more clever and keep the relevant assets</li>
</ul>
openQA Project - action #89077 (Resolved): os-autoinst Makefile is missing symlinks configurationhttps://progress.opensuse.org/issues/890772021-02-24T15:57:21Zybonatakisioannis.bonatakis@suse.com
<p>i tried to use a forked os-autoinst on my local OpenQA instance following the steps from the documentation[0].</p>
<p>From the root of the forked repository i run <code>make</code> which finished without a problem and i started a worker with<br>
<code>sudo /usr/bin/perl /usr/share/openqa/script/worker --isotovideo /home/iob/os-autoinst-distri-opensuse/os-autoinst/isotovideo --instance 1</code><br>
Although the job was complaining about <br>
<code>Please build the tinycv bindings first (see os-autoinst's README)</code>.[1]</p>
<p>With the help of <a class="user active user-mention" href="https://progress.opensuse.org/users/17668">@okurz</a> we found that running <code>make symlinks</code> fixes the issue.<br>
Looking around i believe that the link that was missing was </p>
<pre><code>lrwxrwxrwx 1 iob users 68 Feb 24 16:06 videoencoder -> /home/iob/os-autoinst-distri-opensuse/os-autoinst/build/videoencoder
</code></pre>
<p>Expected:<br>
jobs which use that instance should run without a problem</p>
<p>Actual:<br>
Jobs fails to run asking to build tinycv which it should have done so from the <code>make</code></p>
<p>[0] <a href="https://github.com/os-autoinst/os-autoinst#build-instructions" class="external">https://github.com/os-autoinst/os-autoinst#build-instructions</a><br>
[1] <a href="http://aquarius.suse.cz/tests/5013" class="external">http://aquarius.suse.cz/tests/5013</a></p>
openQA Tests - action #70726 (Resolved): [y] Generate dud file dynamically instead of relying on ...https://progress.opensuse.org/issues/707262020-08-31T10:51:46Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Test fails because the <a href="ftp://openqa.suse.de/SLE-15-Module-Development-Tools-POOL-x86_64-Media1-CURRENT" class="external">ftp://openqa.suse.de/SLE-15-Module-Development-Tools-POOL-x86_64-Media1-CURRENT</a> is not available. </p>
<p>Validation and setup are introduced in <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10770/files" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10770/files</a> but we need a better approach.</p>
<p>We have <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/data/dev_tools.dud" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/data/dev_tools.dud</a> which is basically tarball created with <code>mkdud</code>. Detailed steps are described here:<br>
<code>https://gitlab.suse.de/qsf-y/qa-sle-functional-y/-/blob/master/Development_Guide.md#updating-driver-update-disk-dud-file</code></p>
<p>As per comment below, we have option to pre-install <code>mkdud</code> tool on all 64bit workers, which is a bit of an overkill, but solves the issue: <a href="https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/server.sls" class="external">https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/server.sls</a></p>
<p>As an alternative we can use chained jobs and boot into installed image and generate the dud. To make it more stable we could have used support server image here.</p>
<p>See <a href="http://open.qa/api/testapi/#_upload_asset" class="external">http://open.qa/api/testapi/#_upload_asset</a> for uploading asset. <code>REPO_SLE_MODULE_DEVELOPMENT_TOOLS</code> variable contains the name of the repo.</p>
<p>openQA test in scenario sle-15-SP3-Online-x86_64-dud_development_tools@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4619201/modules/validate_dud_addon_repos/steps/17" class="external">validate_dud_addon_repos</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Same as dud_sdk, but due to bsc#1080292 we cannot use ISO. FTP url is used instead. Limitation is that we use x86_64 url, as cannot create DUD in the runtime, so test cannot be executed on other architectures.</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/4611536" class="external">18.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/4587953" class="external">18.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=Online&machine=64bit&test=dud_development_tools&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #65088 (Resolved): [functional][y] Verify writing conflict from YaST in 70...https://progress.opensuse.org/issues/650882020-03-31T12:34:25Zybonatakisioannis.bonatakis@suse.com
<p>We want to test that config writings from YaST produces certain conflicts.</p>
<p>The implementation as now, contains a couple of yast modules that uses the 70-yast.conf. Some of them that we can use for automation during the installation is</p>
<ul>
<li>net.ipv4.ip_forward</li>
<li>net.ipv4.tcp_syncookies</li>
</ul>
<p>These settings are available in the yast2 network module.</p>
<p>Scope is limited to 64bit on SLES only for the start.</p>
<p>Potential Scenario:</p>
<ol>
<li>Check that module writes settings properly in /etc/sysctl.d/70-yast.conf and not in /etc/sysctl.conf (using yast2 lan module with settings mentioned above)</li>
<li>Set conflicting settings in /etc/sysctl.conf, edit them in yast module verify that yast module reports it</li>
<li>Set conflicting setting in custom file, e.g. /etc/sysctl.d/90-custom.conf , edit them in yast module verify that yast module reports it</li>
</ol>
<p>See Also <a href="https://jira.suse.com/browse/SLE-9077" class="external">https://jira.suse.com/browse/SLE-9077</a> and <a href="https://jira.suse.com/browse/SLE-9088" class="external">https://jira.suse.com/browse/SLE-9088</a></p>
<p>Feature discussion: <a href="https://trello.com/c/uf4RFeC1/3671-sysctld-handling-display-current-settings-and-warn-about-conflicts" class="external">https://trello.com/c/uf4RFeC1/3671-sysctld-handling-display-current-settings-and-warn-about-conflicts</a></p>
<p>Also see <a href="https://progress.opensuse.org/issues/61073#note-13" class="external">https://progress.opensuse.org/issues/61073#note-13</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ol>
<li>in case of conflict all the settings are discarded</li>
</ol>
openQA Tests - action #64731 (Resolved): [functional][y] generate TW image with wicked and use it...https://progress.opensuse.org/issues/647312020-03-24T09:42:11Zybonatakisioannis.bonatakis@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>The yast2_cmdline performs some tests for the command line with the Test Anything Protocol [0].<br>
One of the tap test is for yast2_network module which its tests are relative to wicked and that's why they do not work with NetworkManager,<br>
and it doesnt make sense to run it if this is the case.</p>
<p>Therefore, yast2_cmdline should be executed with wicked setup only.</p>
<p>In openqa, Tumbleweed uses an image which uses NetworkManager. We need to make the test work 'switching' to wicked</p>
<p><a href="https://openqa.opensuse.org/tests/overview?distri=opensuse&version=Tumbleweed&build=20200320&groupid=38" class="external">https://openqa.opensuse.org/tests/overview?distri=opensuse&version=Tumbleweed&build=20200320&groupid=38</a></p>
<p>NOTE: textmode installation has wicked by default, but we use only gnome image</p>
<p>In the image we can switch using following commands:<br>
systemctl disable NetworkManager --now<br>
systemctl enable wicked --now</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ol>
<li>There is an image with wicked enabled in it</li>
<li>yast2_ui_devel uses image with wicked from step 1.</li>
<li>nis_(client|server) test suites use image with wicked from step 1.</li>
</ol>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p>[0] <a href="https://yastgithubio.readthedocs.io/en/latest/how-to-write-tests/#how" class="external">https://yastgithubio.readthedocs.io/en/latest/how-to-write-tests/#how</a></p>