openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-03-04T11:13:23ZopenSUSE Project Management Tool
Redmine 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>
qe-yam - action #71842 (Closed): [y][powervm] select_patterns does not select software linkhttps://progress.opensuse.org/issues/718422020-09-24T12:13:17Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>ssh with x forwarding is known to perform worse than vnc, and problem is that we start to tab before screen is fully loaded.</p>
<p>Straight forward solutions:</p>
<ul>
<li>do more tabbing and get to software section eventually</li>
<li>sync and validate that screen is loaded ( we might be able to simply reuse installation-settings-overview-loaded from tests/installation/installation_overview.pm module )</li>
<li>sync and validate that there is no "analyzing your system" label to be sure that screen is loaded</li>
</ul>
<p>openQA test in scenario sle-15-SP3-Online-ppc64le-ssh-X@ppc64le-hmc-single-disk fails in<br>
<a href="https://openqa.suse.de/tests/4730915/modules/select_patterns/steps/26" class="external">select_patterns</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Conduct an installation using ssh with X-Forwarding. Might only be effective for zVM and powerVM</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/4553477" class="external">13.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=ppc64le&distri=sle&flavor=Online&machine=ppc64le-hmc-single-disk&test=ssh-X&version=15-SP3" class="external">latest</a></p>
qe-yam - action #71830 (Closed): [y] Set default target based on the expectationshttps://progress.opensuse.org/issues/718302020-09-24T11:29:35Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>As it is explained in the <a href="https://bugzilla.suse.com/show_bug.cgi?id=1164556">https://bugzilla.suse.com/show_bug.cgi?id=1164556</a> this is expected as they depend on how system was installed.<br>
This means that even if the "minimal" system role is selected the target is determined by the installed x11 packages and the xdm[0]<br>
Also from the logs </p>
<pre><code>2020-09-23 15:49:22 <1> redcurrant-1(4140) [Pkg] clients/default_target_proposal.rb:237 Pkg Builtin called: IsSelected
2020-09-23 15:49:22 <1> redcurrant-1(4140) [Pkg] Package.cc(IsSelected):505 Tag xdm provided by xdm is selected to install
2020-09-23 15:49:22 <1> redcurrant-1(4140) [Ruby] clients/default_target_proposal.rb:273 Systemd target detection says: X11 packages have been selected for installation
2020-09-23 15:49:22 <1> redcurrant-1(4140) [Ruby] clients/default_target_proposal.rb:268 Detected target proposal 'graphical'
2020-09-23 15:49:22 <1> redcurrant-1(4140) [Ruby] clients/default_target_proposal.rb:231 Setting systemd default target to graphical
2020-09-23 15:49:22 <1> redcurrant-1(4140) [Ruby] modules/services_manager_target.rb:118 New default target has been set: graphical
2020-09-23 15:49:22 <1> redcurrant-1(4140) [Ruby] clients/default_target_proposal.rb:193 Systemd default target is set to 'graphical'
2020-09-23 15:49:22 <1> redcurrant-1(4140) [Interpreter] installation/proposal_store.rb:480 Called YaST client returned.
2020-09-23 15:49:22 <0> redcurrant-1(4140) [Interpreter] installation/proposal_store.rb:480 Called YaST client returned: $["preformatted_proposal":"<ul><li>Graphical mode</li></ul>"]
2020-09-23 15:49:22 <0> redcurrant-1(4140) [Ruby] installation/proposal_store.rb:492 default_target_proposal MakeProposal() returns {"preformatted_proposal"=>"<ul><li>Graphical mode</li></ul>"}
</code></pre>
<p>So we need to fix the validation for the expected target in the system.</p>
<p>[0] <a href="https://github.com/yast/yast-services-manager/blob/master/src/modules/services_manager_target.rb#L126">https://github.com/yast/yast-services-manager/blob/master/src/modules/services_manager_target.rb#L126</a><br>
openQA test in scenario sle-15-SP3-Online-ppc64le-minimal+role_minimal@ppc64le-hmc-4disk fails in<br>
<a href="https://openqa.suse.de/tests/4725230/modules/verify_default_target/steps/5" class="external">verify_default_target</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Like default but explicitly select the system role "minimal". The resulting system should roughly correspond to an unregistered system but with access to modules for optional installation.</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/4557811" class="external">14.2</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=ppc64le&distri=sle&flavor=Online&machine=ppc64le-hmc-4disk&test=minimal%2Brole_minimal&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #71722 (Resolved): [y] test fails in yast2_ihttps://progress.opensuse.org/issues/717222020-09-23T07:21:30Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP3-Online-x86_64-cryptlvm@uefi fails in<br>
<a href="https://openqa.suse.de/tests/4717876/modules/yast2_i/steps/25" class="external">yast2_i</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Maintainers: okurz</p>
<p>Conduct installation with encrypted LVM selected during installation. Generated disk image used in downstream jobs.</p>
<p>(crypt-)LVM installations can take longer, especially on non-x86_64 architectures.</p>
<p>YAML_SCHEDULE=schedule/yaml/cryptlvm/cryptlvm_sle.yaml</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/4717876" class="external">43.1</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/4712337" class="external">42.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=uefi&test=cryptlvm&version=15-SP3" class="external">latest</a></p>
qe-yam - action #71608 (Closed): [y] post_fail_hooks fails with script timeout, no logs collectedhttps://progress.opensuse.org/issues/716082020-09-21T15:26:48Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>there are a few tests that failed in the current build 36.5 but their logs are not presented in the logs&assets<br>
~~the reason (at least in the allmodules+allpatterns+registration seems to be a timeout</p>
<pre><code>�[0m�[37m[2020-09-17T15:35:54.176 CEST] [debug] post_fail_hook failed: script timeout: dmesg | grep "Out of memory" at /usr/lib/os-autoinst/testapi.pm line 1121.
</code></pre>
<p>The post_fail_hook should never fail, ideally, at least not fatal and it should continue even if some of the commands fail.~~</p>
<p>Problem was with sysrq command, which got fixed with <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/11054/files" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/11054/files</a><br>
But we don't switch to log console for whatever reason, and next step fails, we even don't see it typed properly and somehow byebug is called.</p>
<p>openQA test in scenario sle-15-SP3-Full-x86_64-allmodules+allpatterns+registration@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4701956/modules/addon_products_sle/steps/59" class="external">addon_products_sle</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Full Medium installation that covers the following cases:<br>
1. Additional modules enabled using SCC (Legacy, Development Tools, Web and<br>
Scripting, Containers, Desktop Applications);<br>
2. All patterns installed;<br>
3. System registration is skipped during installation;<br>
4. Installation is validated by successful boot and that YaST does not<br>
report any issues;<br>
5. Registration is performed on the installed system.</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/4693343" class="external">34.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/4688752" class="external">33.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=Full&machine=64bit&test=allmodules%2Ballpatterns%2Bregistration&version=15-SP3" class="external">latest</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 #70693 (Resolved): [y][fast] test fails in validate_mirror_reposhttps://progress.opensuse.org/issues/706932020-08-31T07:06:00Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>assert is wrong. it should use URI but it is alias.</p>
<p>openQA test in scenario sle-15-SP3-Full-x86_64-gnome_http@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4612409/modules/validate_mirror_repos/steps/13" class="external">validate_mirror_repos</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Maintainer: jrivera. Install using http, https or samba as a repo source.<br>
For https suse.de has self-signed certificate, so it is required SKIP_CERT_VALIDATION=1</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/4610474" 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/4575365" 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=Full&machine=64bit&test=gnome_http&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #70237 (Resolved): [y] Add validations for textmode of ppc64le https://progress.opensuse.org/issues/702372020-08-19T11:11:44Zybonatakisioannis.bonatakis@suse.com
<p>Test suites @ppc64le-hmc and @ppc64le-spvm lacks for validations. <br>
We need to add the relevant modules but they fail at the moment. <a href="https://openqa.suse.de/tests/4565553" class="external">https://openqa.suse.de/tests/4565553</a></p>
openQA Tests - action #70228 (Resolved): [y] restore checkmedia tests in YaST group for virtualiz...https://progress.opensuse.org/issues/702282020-08-19T10:10:32Zybonatakisioannis.bonatakis@suse.com
<p>Revert <a href="https://gitlab.suse.de/qsf-y/qa-sle-functional-y/-/merge_requests/266/diffs" class="external">https://gitlab.suse.de/qsf-y/qa-sle-functional-y/-/merge_requests/266/diffs</a> and make sure that tests pass as they fail in the current build 14.2</p>
<p>Main hint is parameters mismatch, so might be that we have missing settings in the test suite to make it work on those backends.</p>
<p><a href="https://openqa.suse.de/tests/4559109" class="external">mediacheck@svirt-hyperv</a><br>
<a href="https://openqa.suse.de/tests/4559110" class="external">mediacheck@svirt-hyperv-uefi</a><br>
<a href="https://openqa.suse.de/tests/4559111" class="external">mediacheck@svirt-xen-hvm</a></p>
openQA Tests - action #70153 (Resolved): [y] system_state should upload collected datahttps://progress.opensuse.org/issues/701532020-08-18T05:05:50Zybonatakisioannis.bonatakis@suse.com
<p>The <code>system_state.pm</code>[0] is just collecting data from the process list and system loads. I think it would be meaningful to upload the collected data to the OpenQA logs and assets, wherever this is used. Doing such we can review those data afterwards as it is tricky to add automatic validation on the output.</p>
<p>[0] <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/console/system_state.pm" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/console/system_state.pm</a></p>
<p>So basically we can:</p>
<ul>
<li>Fix the text uploading the file.</li>
<li>Additionally, perform a bit of research about where the post fail is trigger with ps and from which class you need to inherit to have it.</li>
<li>Consider if we need this module.</li>
</ul>
openQA Tests - action #69862 (Resolved): [y] supportserver_generator_from_hdd fails for x86_64https://progress.opensuse.org/issues/698622020-08-11T10:19:46Zybonatakisioannis.bonatakis@suse.com
<p><a href="https://openqa.suse.de/tests/4546589#step/configure/12" class="external">https://openqa.suse.de/tests/4546589#step/configure/12</a><br>
<a href="https://openqa.suse.de/tests/4546588#step/configure/12" class="external">https://openqa.suse.de/tests/4546588#step/configure/12</a></p>
qe-yam - action #69142 (Resolved): [y] Adjust bootloader for MM on aarch64https://progress.opensuse.org/issues/691422020-07-20T13:34:04Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>aarch64 uses uefi in the bootloader. <br>
The bootloader for the MM tests are not setup properly the parameters as you can see for instance on remote_ssh_target_ftp in <a href="https://openqa.suse.de/tests/4466996/modules/bootloader_start/steps/8" class="external">bootloader_start</a></p>
<p>the bootloader for the x86_64 loads parameters as you can find in <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/installation/bootloader.pm#L59" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/installation/bootloader.pm#L59</a>. basically <code>ssh</code> and <code>ssh.password</code>. Other parameters might are required based on the media. for example, Online installation, might need dns.</p>
<p>bootloader_start uses the correct bootloader as now.</p>
<p>We are missing at least following boot params:<br>
nameserver= ssh=1 sshpassword=nots3cr3t for ssh<br>
nameserver= vnc=1 vncpassword=nots3cr3t for vnc</p>
<p>So we need to make sure those are added to uefi bootloader.</p>
<p>Don't hesitate to contact Anton Smorodsky in case you need support with MM tests on arm.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li>uefi bootloader passes the required parameters for networking(ssh, vnc, etc)</li>
</ul>
openQA Project - action #68143 (Resolved): [y] Implement navigation to the schedule from the jobhttps://progress.opensuse.org/issues/681432020-06-16T13:18:47Zybonatakisioannis.bonatakis@suse.com
<p>As tester<br>
I want to be able to navigate easily to the schedule file of the test</p>
<p>we can implement same handling as we have for test modules code.</p>
<p>We can have it handled in similar way as test module code or at least have some improved usability using.</p>
openQA Tests - action #67285 (Resolved): [y] Adjust installation in autoyast_salt to the recent c...https://progress.opensuse.org/issues/672852020-05-26T14:24:50Zybonatakisioannis.bonatakis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>now we support several formulas (suse manager and not suse manager), several pillars etc.<br>
in order to make everything consistent, we changed how the salt.tar.gz is organized, and the "formulas" directories has now two directories (states and metadata). <br>
the changes are <a href="https://github.com/yast/yast-configuration-management/pull/81" class="external">https://github.com/yast/yast-configuration-management/pull/81</a> and <a href="https://github.com/yast/yast-configuration-management/pull/80" class="external">https://github.com/yast/yast-configuration-management/pull/80</a>.</p>
<p>in theory we would need to update the tar file with the new structure. The rest should remain the same(xml, installation flow)</p>
<p>Contact to <a class="user active user-mention" href="https://progress.opensuse.org/users/15330">@IGonzalezSosa</a> for support</p>
<p>openQA test in scenario sle-15-SP2-Online-x86_64-autoyast_salt@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4283662/modules/installation/steps/46" 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>Test installation using AutoYaST plus salt formulas.</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/4281272" class="external">202.5</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/4277536" class="external">201.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=autoyast_salt&version=15-SP2" 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>