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 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-702f1aa3-show, #collapse-702f1aa3-hide').toggle(); $('#collapse-702f1aa3').fadeToggle(150);; return false;" id="collapse-702f1aa3-show" class="icon icon-collapsed collapsible">autoinst-log.txt...</a><a href="#" onclick="$('#collapse-702f1aa3-show, #collapse-702f1aa3-hide').toggle(); $('#collapse-702f1aa3').fadeToggle(150);; return false;" id="collapse-702f1aa3-hide" class="icon icon-expanded collapsible" style="display:none;">autoinst-log.txt...</a><div id="collapse-702f1aa3" 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>
qe-yam - action #113725 (Rejected): Make autoyast tests exit when the autoyast profile encounter ...https://progress.opensuse.org/issues/1137252022-07-18T13:35:03Zybonatakisioannis.bonatakis@suse.com
<a name="observation"></a>
<h1 >observation<a href="#observation" class="wiki-anchor">¶</a></h1>
<p>What happens is that when the autoyast profile is wrong or not found, the tests keep trying to match needles and continue.</p>
<p>One such case is [0]. The problem appears something like 5 minutes after it starts but keeps running for 2h where the job time limits are reached.<br>
Because this cause a slow feedback loop of the tests, in combination of the resources which are occupied without any good reason i would like to propose a solution.</p>
<p>the easier would be to match a needle with the popup and abort. <br>
I dont know if there is already a module for it but we could run a check on the xml profile before installation module. I am not sure but i think there was something implemented for this specific reason. </p>
<p>To reproduce:<br>
you can use <a href="https://gist.github.com/b10n1k/bca22757c5e4eb11473ceda30820f6d2" class="external">https://gist.github.com/b10n1k/bca22757c5e4eb11473ceda30820f6d2</a> as <u>profile.xml</u></p>
<p>Actual results:<br>
<a href="http://aquarius.suse.cz/tests/11324#step/installation/2" class="external">http://aquarius.suse.cz/tests/11324#step/installation/2</a></p>
<p>Expected:<br>
i am not sure about that. should that be one of the following:</p>
<ul>
<li>Exit after some rational time when the error exists.</li>
<li>terminate needle checking after some expected time??
the while loop have specific expectations during installation. When those expectation do not ever match, the loop run for even.</li>
<li>Validate xml before installation and exit then if problem appears</li>
</ul>
<p>[0] <a href="http://aquarius.suse.cz/tests/11324" class="external">http://aquarius.suse.cz/tests/11324</a></p>
qe-yam - action #71026 (Rejected): [y] Validate updated package version with self_updatehttps://progress.opensuse.org/issues/710262020-09-07T07:33:28Zybonatakisioannis.bonatakis@suse.com
<p>With the work on <a href="https://bugzilla.suse.com/show_bug.cgi?id=1175614" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1175614</a> done, we can check what version the self update download and use in the inst-sys. Rodion has already created validation module <code>tests/installation/validate_self_update.pm</code> checking that the feature attempts to download some packages from the update repo but it does not check/compare the package version between the default inst-sys and the update repo. The inst-sys stores the package version in <code>/.packages.root</code>. With yast2-installation-4.3.16 and above we should find <code>/.packages.self_update</code> file which we can use to compare</p>
qe-yam - action #69259 (Rejected): [y] Test fully qualified domain name as an input for yast2-net...https://progress.opensuse.org/issues/692592020-07-23T06:10:53Zybonatakisioannis.bonatakis@suse.com
<p>Although it is recommended to not use a FQDN as the static hostname there is not a restriction in the kernel or hostnamectl to use it and thus, there should not be a restriction in YaST in case that the user has a use case in which it is needed. YaST has recent changes in yast2-network to address this.</p>
<p>This is not typical use case, so low priority.</p>
openQA Tests - action #68908 (Rejected): [y] Remove deprecated sections from autoyast profilehttps://progress.opensuse.org/issues/689082020-07-13T07:10:25Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP2-Online-x86_64-autoyast_tftp@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4445217/modules/installation/steps/5" class="external">installation</a></p>
<p>As the warning shows there are sections that they have removed from the xml profile.<br>
We need to adjust the xml.</p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Tests installation with tftp configured. Uses profile from <a href="https://github.com/yast/aytests-tests" class="external">https://github.com/yast/aytests-tests</a> repo.</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/4424929" class="external">209.2</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/4344368" class="external">209.2</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=autoyast_tftp&version=15-SP2" class="external">latest</a></p>
qe-yam - action #65447 (Rejected): Extend form of salt-formulas testhttps://progress.opensuse.org/issues/654472020-04-08T11:25:00Zybonatakisioannis.bonatakis@suse.com
<p>we want to extend smoke test for salt formulas using more element in the UI.<br>
As now the formula in use looks like <a href="http://aquarius.suse.cz/tests/2209#step/installation/9" class="external">http://aquarius.suse.cz/tests/2209#step/installation/9</a>.</p>
<p>we need to edit the /data/yast2/salt.tar.gz modify the formula/motd/form.yaml.</p>
<p>take a look at the relative ticket <a href="https://progress.opensuse.org/issues/49550" class="external">https://progress.opensuse.org/issues/49550</a></p>
<p>Also good to add validation for cloned profile( need to be added)</p>
<p>** Acceptance criteria</p>
<ul>
<li>Validation of cloned profile for relevant part</li>
<li>use additional components in the formula and we validate them after installation</li>
</ul>
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 #64165 (Rejected): [functional][y][periodic] test fails in nis_serverhttps://progress.opensuse.org/issues/641652020-03-03T20:19:53Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>the test fails sporadically when the shortcut alt-f fails. As it is shown in the screenshot it the 'f' appears at the end of NIS domain name.</p>
<p>###Suggestion###</p>
<ul>
<li>add some timeout might solve the problem</li>
</ul>
<p>openQA test in scenario sle-15-SP2-Online-x86_64-nis_server@64bit fails in<br>
<a href="https://openqa.suse.de/tests/3949165/modules/nis_server/steps/47" class="external">nis_server</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p><a href="https://progress.opensuse.org/issues/9900" class="external">https://progress.opensuse.org/issues/9900</a><br>
this is only the working part, there are few bugs</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/3939234" class="external">148.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/3927982" class="external">146.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=nis_server&version=15-SP2" class="external">latest</a></p>
openQA Tests - action #62495 (Closed): [functional][y][opensuse] Update support_server on o3 for ...https://progress.opensuse.org/issues/624952020-01-21T17:54:53Zybonatakisioannis.bonatakis@suse.com
<p>We need to create and update the support_server used in remote installation in openqa.opensuse.org. The purpose is to fix the problem appeared in the associated ticket which enabled the vnc remote installation[0] and adjust the tests removing the workaround(remote_target.pm:L28). The work in the spike[1] shows that this should make the trick. </p>
<p>one way to generate a support_server is:<br>
{{</p>
<pre><code class="bash syntaxhl" data-language="bash"><span class="nb">sudo</span> /usr/share/openqa/script/client <span class="nb">jobs </span>post <span class="nv">DISTRI</span><span class="o">=</span>opensuse <span class="nv">VERSION</span><span class="o">=</span>15.2 <span class="nv">ISO</span><span class="o">=</span>openSUSE-Leap-15.0-DVD-x86_64.iso <span class="nv">ARCH</span><span class="o">=</span>x86_64 <span class="nv">FLAVOR</span><span class="o">=</span>DVD <span class="nv">TEST</span><span class="o">=</span>supportserver_generator <span class="nv">MACHINE</span><span class="o">=</span>64bit <span class="nv">DESKTOP</span><span class="o">=</span>gnome <span class="nv">INSTALLONLY</span><span class="o">=</span>1 <span class="nv">AUTOYAST</span><span class="o">=</span>supportserver/autoyast_supportserver_x86.xml <span class="nv">SUPPORT_SERVER_GENERATOR</span><span class="o">=</span>1 <span class="nv">PUBLISH_HDD_1</span><span class="o">=</span>supportserver_15_0_gnome_iob.qcow2 <span class="nt">--host</span> https://openqa.opensuse.org/<span class="sb">```</span>
where:
<span class="nv">ISO</span><span class="o">=</span>the iso file to use <span class="k">for </span>the image
<span class="nv">AUTOYAST</span><span class="o">=</span>one of the xml files <span class="k">in </span>the os-autoinst-distri-opensuse/data directory
<span class="o">}}</span>
The problem is that this didnt work quite well <span class="k">for </span>me[2] as it cant find the packages <span class="k">in </span>the repos. So some extra effort might required.
<span class="c">## Acceptance criteria</span>
- no workaround to get out of the yast <span class="k">in </span>target machine
- the remote ssh and vnc tests should get to the desktop after the installation finish
- it has been observed a segmentation fault <span class="k">in </span>ssh. <span class="k">if </span>this does not appear any more with newer image, that s good, otherwise a bug should be filed.
<span class="c">## Suggestions</span>
- create a xml, run the support_server generator and publish the image
- use an existing qcow and modify it to include the packages that it needs
<span class="o">[</span>0] https://progress.opensuse.org/issues/52310
<span class="o">[</span>1] https://progress.opensuse.org/issues/62096
<span class="o">[</span>2] https://openqa.opensuse.org/tests/1150274
</code></pre> openQA Tests - action #59061 (Rejected): test fails in installationhttps://progress.opensuse.org/issues/590612019-11-05T07:26:11Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Seems like a problem with the control.xml configuration as it complains about the not selected base product. </p>
<p>openQA test in scenario sle-15-SP2-Online-x86_64-autoyast_disk_as_md_member@64bit fails in<br>
<a href="https://openqa.suse.de/tests/3552993/modules/installation/steps/3" 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>Validate partitioning for autoyast installation when using disks as Multiple Device member. Uses two devices.</p>
<p>The test verifies that the following configuration of the installed system match the parameters in autoyast profile:</p>
<ol>
<li>Number of partitions on MD RAID;</li>
<li>RAID level;</li>
<li>Mount points for MD partitions. Maintainer: <a href="mailto:oorlov@suse.de">oorlov@suse.de</a></li>
</ol>
<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/3529436" class="external">72.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=autoyast_disk_as_md_member&version=15-SP2" class="external">latest</a></p>
openQA Project - action #49697 (Rejected): [Bug] Needle panel shows incorrect matcheshttps://progress.opensuse.org/issues/496972019-03-26T12:41:55Zybonatakisioannis.bonatakis@suse.com
<p>I found an inconsistency between the <a href="https://openqa.suse.de/admin/needles" class="external">https://openqa.suse.de/admin/needles</a> table and the report in the corresponding test. The /admin/needles shows that the needle never matched but the test shows 100% match. </p>
<p>To reproduce:</p>
<ul>
<li>goto <a href="https://openqa.suse.de/tests/2737496#step/select_patterns_and_packages/89" class="external">https://openqa.suse.de/tests/2737496#step/select_patterns_and_packages/89</a> and check the dropdown list for inst-overview-20170403. this should be 100% in this specific job</li>
<li>visit <a href="https://openqa.suse.de/admin/needles" class="external">https://openqa.suse.de/admin/needles</a> and filter for inst-overview. The inst-overview-20170403.json 's last match is never</li>
</ul>