openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-03-25T11:05:24ZopenSUSE Project Management Tool
Redmine qe-yam - action #157873 (New): Merge vars HDDVERSION,FROM_VERSION and ORIGIN_SYSTEM_VERSIONhttps://progress.opensuse.org/issues/1578732024-03-25T11:05:24Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Scope"></a>
<h1 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h1>
<p>Currently we are using three different variables HDDVERSION,FROM_VERSION and ORIGIN_SYSTEM_VERSION to describe the same thing.<br>
We should decide on which of these to keep and replace other vars accordingly. This can be tricky as the vars are not only used in the yaml Job groups but in the openqa code as well.</p>
<a name="Acceptance-Criteria"></a>
<h1 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h1>
<ul>
<li>Discuss with the team or create poll to decide which name to keep (I would go with HDDVERSION)</li>
<li>Replace the rest of the var names with the name of choice</li>
<li>Modify openqa code accordingly for our tests and run VRs.</li>
<li>Notify other teams that might use the modified code so that they rename their vars in their job group settings</li>
</ul>
qe-yam - action #157474 (Resolved): Remove package Hub from SLE 12 SP5 migrations and resolve ven...https://progress.opensuse.org/issues/1574742024-03-18T12:32:04Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>According to the response in a dependency issue bug report: <a href="https://bugzilla.suse.com/show_bug.cgi?id=1209498#c3" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1209498#c3</a> <br>
We should remove packagehub from migration scenarions as it is not L3 supported.<br>
In the PRD is explicitly mentioned about not supported for SLE 12 SP5, for SLE 15 SPN is on best effort.</p>
<p>Latest conflict issues for two migration tests that include phub prior migration: <a href="https://openqa.suse.de/tests/13793854#step/resolve_dependency_issues/28" class="external">https://openqa.suse.de/tests/13793854#step/resolve_dependency_issues/28</a> and <a href="https://openqa.suse.de/tests/13793867#step/resolve_dependency_issues/3" class="external">https://openqa.suse.de/tests/13793867#step/resolve_dependency_issues/3</a></p>
<p>Additionally we have a mechanism to resolve vendor changes for the SLE 15 SP5 failures related with phub.</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: phum module removed from SLE 12 SP5 migrations.<br>
<strong>AC2</strong>: Vendor changes for SLE 15 SP5 addressed via setting that activate that testing path in the UI.</p>
qe-yam - action #157234 (Resolved): Adjust zfcp multipath validation now with dynamic wwidhttps://progress.opensuse.org/issues/1572342024-03-14T10:56:24Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>The s390x-zfcp test hasn't ran past first steps for a long time, so there have been some hardware changes in the meantime that cause failure while validating the wwid of the disk. See <a href="https://openqa.suse.de/tests/13765049/modules/validate_zfcp_multipath/steps/9" class="external">validate_zfcp_multipath</a>. There have been some proposals to remove the hardcoded wwid value as it is not guaranteed to be the same for every test run. According to a <a href="https://suse.slack.com/archives/C02CLB2LB7Z/p1710329927799739" class="external">slack discussion</a> we can instead extract the wwpn value (probably at an earlier step of the test) and validate it including the size during module validate_zfcp_multipath</p>
<p>If we want to ensure that the same disk is still present which was added, then we can find that out with commands like <code>multipath -ll</code> , <code>lszfcp</code> or <code>zfcp_host_configure</code></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Implement above validation</p>
qe-yam - action #154726 (New): revert s390x temporary condition ones suseconnect-ng package is up...https://progress.opensuse.org/issues/1547262024-02-01T10:56:39Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Some s390x migration tests that use suseconnect-ng while patch_sle, where failing due to PR: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18483" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18483</a> as the latest changes for suseconnect-ng package were not included in s390x iso.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>The temporary fix for this issue was implemented here: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18555#event-11664768890" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18555#event-11664768890</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<ul>
<li>Keep an eye on s390x tests:
offline_sles15sp4_pscc_basesys-srv-desk-phub_def_full<br>
offline_sles15sp4_pscc_basesys-srv-lp-contm-lgm-tsm-pcm-wsm_all_full<br>
offline_sles15sp4_pscc_basesys-srv-lp_def_full</li>
</ul>
<p>Once they fail due to license appearance, revert the temporary fix PR</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>Relevant progress ticket: <a href="https://progress.opensuse.org/issues/154120" class="external">https://progress.opensuse.org/issues/154120</a></p>
qe-yam - action #153964 (In Progress): [Research: 24h] Check how to not need to set YUI_REST_API=...https://progress.opensuse.org/issues/1539642024-01-19T13:03:24Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Currently, we are distinguishing the libuyi test from the non-libyui tests by using the variable YUI_REST_API.<br>
It would be more convenient to create a different way, based on the version of the os (=+sles15-sp3). <br>
The challenge would be to avoid using multiple conditions in the os-autoinst-opensuse-distro repo.<br>
This settings is tightly coupled with the yaml schedule, so it might require some research what are all the points in the code affected.</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Find strategy to avoid setting YUI_REST_API at all.</p>
qe-yam - action #153154 (New): Replace different arch yaml schedules with one for continuous migr...https://progress.opensuse.org/issues/1531542024-01-05T10:36:25Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Test offline_sle12sp5_sles15sp4_sles15sp_latest_*_ph0 from migration_miscellaneous job group has a dedicated yaml schedule for each arch. The schedules are quite similar and could be replaced by one, if properly written. The differences are mainly the bootloader (bootloader_start can replace all), isosize module for aarch64 and ppc64le and for s390x reconnect_mgmt_console module instead of grub_test module. Files:<br>
schedule/migration/migration_offline_scc_deregistration_x86_64.yaml <br>
schedule/migration/migration_offline_scc_deregistration_s390x.yaml<br>
schedule/migration/migration_offline_scc_deregistration_aarch64.yaml<br>
schedule/migration/migration_offline_scc_deregistration_ppc64le.yaml </p>
<p><strong>Acceptance criteria</strong></p>
<ul>
<li>Unify the above files to one</li>
<li>Research which archs should include isosize module (preferably all or none)</li>
<li>Edit the Job group yaml to point to the new schedule.</li>
</ul>
qe-yam - action #153113 (New): Create default settings for each product in Job groups yamlhttps://progress.opensuse.org/issues/1531132024-01-04T13:41:49Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Currently, in the job groups yaml files, we have a lot of repetition, thus everytime we have to make some changes, we need to edit a lot of lines.<br>
This type of work, besides being tiresome is error prone.</p>
<p>We can create some defaults for every product that will be inherited by all the product tests. Example:</p>
<p>default_15sp4_config: &15sp4_config<br>
HDDVERSION: '15-SP4'<br>
SCC_REGCODE_LTSS: somecode</p>
<p>some_15sp4_test:<br>
settings:<br>
<<:*15sp4_config</p>
<p>We could also try to add a variable for ltss enablement in the default settings, so that we don't need to edit every test line when we want to add the addon. Example LTSS='ltss'/''<br>
SCC_ADDONS: 'serverapp,base,%LTSS%'</p>
qe-yam - action #152685 (New): Add typescript syntax check in Playwright repo CI/CDhttps://progress.opensuse.org/issues/1526852023-12-15T13:21:17Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>In <a href="https://github.com/jknphy/e2e-agama-playwright" class="external">Playwright repo</a> we have currently set the basis for CI/CD <a href="https://progress.opensuse.org/issues/134441" class="external">poo#134441</a> after merging: <a href="https://github.com/jknphy/e2e-agama-playwright/pull/30" class="external">https://github.com/jknphy/e2e-agama-playwright/pull/30</a><br>
Currently, the only check available is the typescript formatting, according to file tsfmt.json (complying with the default formatting by vscode). We should enhance the checks by verifying the typescript syntax. In case there is a toll that can verify both syntax and formatting, the typescript-formatter can be completely removed from the workflow.</p>
<p><strong><em>Acceptance Criteria</em></strong></p>
<ul>
<li>The CI in Playwright repo should check the typescript syntax for errors.</li>
<li>Create test actions to verify expected failure and success of the CI.</li>
</ul>
qe-yam - action #152683 (New): Add check for existence of imported files in Playwright repo CI/CDhttps://progress.opensuse.org/issues/1526832023-12-15T13:16:36Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>In <a href="https://github.com/jknphy/e2e-agama-playwright" class="external">Playwright repo</a> we have currently set the basis for CI/CD <a href="https://progress.opensuse.org/issues/134441" class="external">poo#134441</a> after merging: <a href="https://github.com/jknphy/e2e-agama-playwright/pull/30" class="external">https://github.com/jknphy/e2e-agama-playwright/pull/30</a><br>
Currently, the only check available is the typescript formatting, according to file tsfmt.json (complying with the default formatting by vscode). We should enhance the checks in the CI, by adding a step that will get the imported files (lib/actor/page etc) ignoring the "import { type Page } from '@playwright/test';" . It is recommended to create a script directory and place a script inside that will be called by the CI steps in .github/workflows/ci.yaml, instead of polluting the ci.yaml.</p>
<p><strong><em>Acceptance criteria</em></strong></p>
<ul>
<li>The CI should check if the imported files exist in the repo.</li>
<li>Create test actions to verify expected failure and success of the CI.</li>
</ul>
qe-yam - action #133271 (New): Make agama auto installation test work for s390xhttps://progress.opensuse.org/issues/1332712023-07-25T08:10:51Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Currently, we have 3 <a href="https://openqa.opensuse.org/tests/overview?distri=alp&version=agama-2.1-staging&build=1.42&groupid=96" class="external">agama auto installation tests</a> on o3 for x86_64 and aarch64. We could schedule the dolomite test for z/VM on o3 as well. <br>
The bootloader_s390 will need some modifications in order to enter the proper parameters in the parmfile. The details of auto installation on z/VM are described <a href="https://confluence.suse.com/pages/viewpage.action?pageId=1286701688" class="external">here</a>.<br>
The test schedule will have to include handle_reboot or reconnect_mgmt_console for the console reconnection. <br>
In the autoyast profile of <a href="https://openqa.opensuse.org/tests/latest?arch=s390x&distri=opensuse&flavor=DVD&machine=s390x-zVM-vswitch-l2&test=autoyast_zvm&version=Tumbleweed" class="external">autoyast_zvm</a> test suite, we have added the following script for successful reconnection:</p>
<pre><code> <scripts>
<!-- permit root login, password login and pubkeys login -->
<post-scripts config:type="list">
<script>
<filename>post-script.sh</filename>
<interpreter>shell</interpreter>
<location/>
<feedback config:type="boolean">false</feedback>
<source><![CDATA[
sshd_config_file="/etc/ssh/sshd_config.d/permit_root_login.conf"
echo -e "PermitRootLogin yes\nPubkeyAuthentication yes\nPasswordAuthentication yes" > $sshd_config_file
[ -d /root/.ssh ] || mkdir -p /root/.ssh; chmod 700 /root/.ssh
touch /root/.ssh/authorized_keys; chmod 600 /root/.ssh/authorized_keys
echo "##Authorized-Keys##" >> /root/.ssh/authorized_keys
]]>
</source>
</script>
</post-scripts>
</scripts>
</code></pre> qe-yam - action #132839 (New): Use Mojo race condition where applicable in future testshttps://progress.opensuse.org/issues/1328392023-07-17T07:51:48Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>After PR: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17150" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17150</a><br>
for handling the java license popup during installation settings, it was noticed and commended here <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17150#discussion_r1251875831" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17150#discussion_r1251875831</a> <br>
that we can use race conditions. An available library for openqa workers, here: <a href="https://docs.mojolicious.org/Mojo/Promise" class="external">https://docs.mojolicious.org/Mojo/Promise</a><br>
We could start using this after we investigate the functionality and proper syntax. Ask for help, if needed, in slack channel #discuss-perl</p>
<p><strong>Acceptance criteria</strong></p>
<ul>
<li>Research how we can use it in our testing code, make an example by refactoring existing code.</li>
<li>Make a demo for sharing the knowledge.</li>
</ul>
qe-yam - action #129460 (New): Create sync scripts for SCC/SMT/RMT servershttps://progress.opensuse.org/issues/1294602023-05-17T09:35:36Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>When we have to do manual testing for milestone builds, there is a procedure that can be automated, described <a href="https://confluence.suse.com/pages/viewpage.action?pageId=1118405556" class="external">here</a><br>
We should try to create scripts in order to make the procedure much faster and also include some clean up in the beginning on each script, in order to avoid running out of space on the SMT/RMT servers due to hoarding of old updates/products.</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong> : find out which products are necessary for SMT and RMT servers<br>
<strong>AC2</strong> : find ways to efficiently clean up the old data e.g. smt-mirror --cleanup will remove majority of data from /srv/www/htdocs/SUSE/ but will leave the old unused product directories there, so on next cleanup, we need to wait for these directories to be scanned as well. <br>
<strong>AC3</strong> : Create scripts with sufficient comments/documentation for easy maintenance, that will automate the SMT/RMT maintenance.<br>
<strong>AC4</strong> : Update confluence page</p>
openQA Project - action #127739 (New): ASSET_1 gets outdated value when using openqa-clone-custom...https://progress.opensuse.org/issues/1277392023-04-17T07:59:50Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>When using openqa-clone-custom-git-refspec in order to clone a job, the value of ASSET_1 or any other ASSET get's the value from settings. But usually, the ASSET uploaded after the original job is run, gets another file name. For example, if ASSET_1=dev_tools.dud in settings, the original job will have uploaded ASSET_1=10931294-dev_tools.dud and the cloned job will fail because it cannot find dev_tools.dud with error:<br>
[info] [<a class="issue tracker-4 status-5 priority-4 priority-default closed" title="action: Breadcrumbs (Closed)" href="https://progress.opensuse.org/issues/555">#555</a>] Downloading "dev_tools.dud" from "<a href="http://openqa.suse.de/tests/10932003/asset/other/dev_tools.dud" class="external">http://openqa.suse.de/tests/10932003/asset/other/dev_tools.dud</a>"<br>
[info] [<a class="issue tracker-4 status-5 priority-4 priority-default closed" title="action: Breadcrumbs (Closed)" href="https://progress.opensuse.org/issues/555">#555</a>] Download of "/var/lib/openqa/cache/openqa.suse.de/dev_tools.dud" failed: 404 Not Found</p>
<p>In order to have a successful cloning, ASSET_1 has to be manually set to ASSET_1=10931294-dev_tools.dud while typing the refspec command.<br>
#openqa-clone-custom-git-refspec <a href="https://github.com/sofiasyria/os-autoinst-distri-opensuse/tree/master" class="external">https://github.com/sofiasyria/os-autoinst-distri-opensuse/tree/master</a> <a href="https://openqa.suse.de/tests/10931666" class="external">https://openqa.suse.de/tests/10931666</a> ASSET_1='10931294-dev_tools.dud'</p>
<p>It would be useful to automate the above process. </p>
openQA Project - action #87725 (New): MULTIPATH backend variable doesn't set HDDMODEL for aarch64https://progress.opensuse.org/issues/877252021-01-13T16:48:15Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>According to the definition of the variable, if MULTIPATH=1:<br>
"Add HDD drives as multipath devices. Override HDDMODEL to virtio-scsi-pci"</p>
<p>That indeed happens when used on 64bit or ppc64le, but for aarch64, HDDMODEL remains to default value "virtio-blk-device". Test fails with error: "Device 'virtio-blk-device' can't go on SCSI bus". In order for the test to work, HDDMODEL needs to be set to "scsi-hd".</p>
openQA Tests - action #72184 (New): [virtualization][y] Select_console fails sporadically for svi...https://progress.opensuse.org/issues/721842020-10-01T15:10:12Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>There is a sporadic failure of approximately 17%, for prepare_data module for yast2_gui test suite. The SUT seems to be freezing with black screen, when select_console is called.</p>
<p>It is notable that by simplifying the module to:</p>
<pre><code>sub run {
select_console 'root-console';
}
1;
</code></pre>
<p>it still displays the same percentage of failure.</p>
<p>The issue is not present in case of using xterm and chvt 6.</p>
<pre><code>sub run {
x11_start_program('xterm');
wait_still_screen(5);
become_root;
assert_script_run "chvt 6";
assert_screen "tty6-selected";
}
1;
</code></pre>
<p>Unfortunately, the logs are not helpful. When successfully switching to tty6, the autoinst logs contain:<br>
[2020-09-30T17:28:05.896 CEST] [debug] <<< testapi::select_console(testapi_console="root-console")<br>
....<br>
[ 82.601276] <strong>systemd[1]: Started Getty on tty6.</strong></p>
<p>Looking at the logs from failed runs, the above phrase is missing.</p>
<p>openQA test in scenario sle-15-SP3-Online-x86_64-yast2_gui@svirt-xen-hvm fails in<br>
<a href="https://openqa.suse.de/tests/4718229/modules/prepare_test_data/steps/3" class="external">prepare_test_data</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p><a href="https://openqa.suse.de/tests/4752856" class="external">48.1</a></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=svirt-xen-hvm&test=yast2_gui&version=15-SP3" class="external">latest</a></p>