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 #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 Infrastructure - action #127337 (Resolved): Some s390x workers have been failing for all j...https://progress.opensuse.org/issues/1273372023-04-06T09:04:57Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>There are quite a few s390x failures on booting, so after comparing test results, the observation that workers:<br>
<a href="https://openqa.suse.de/admin/workers/1328" class="external">grenache-1:30</a><br>
<a href="https://openqa.suse.de/admin/workers/1348" class="external">grenache-1:40</a><br>
<a href="https://openqa.suse.de/admin/workers/1809" class="external">grenache-1:43</a><br>
<a href="https://openqa.suse.de/admin/workers/1812" class="external">grenache-1:44</a></p>
<p>have been constantly failing for all jobs for the last 11 months. It seeems that before this period of time, the workers (besides grenache-1:44 which was still s390x) were used for ipm and ppc tests and they are now switched to s390x service.</p>
<p>A very frequent error message is : Test died: unexpected end of data at /usr/lib/os-autoinst/consoles/VNC.pm line 187. <a href="https://openqa.suse.de/tests/10869590#step/bootloader_start/39" class="external">example</a> </p>
<p>Possibly related with: <a href="https://progress.opensuse.org/issues/108266" class="external">https://progress.opensuse.org/issues/108266</a></p>
<p>Note: we noticed this issue, after creating a generic s390x-kvm machine, to take advantage of s390-kvm WORKER_CLASS. It seems that other current s390x jobs that are designated to use s390x-kvm-sle12/15 do not run on these workers. For more information, see : <a href="https://progress.opensuse.org/issues/126293" class="external">https://progress.opensuse.org/issues/126293</a></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>
openQA Project - action #69313 (Resolved): When using refspec for ppc for a particular job, PRODU...https://progress.opensuse.org/issues/693132020-07-24T10:25:20Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>While attempting to run refspecs for test "autoyast_reinstall" job on various architectures, I faced an issue specifically on ppc64le. The PRODUCTDIR needs to be set manually like following: <br>
<code>openqa-clone-custom-git-refspec https://github.com/sofiasyria/os-autoinst-distri-opensuse/tree/ac68803 https://openqa.suse.de/tests/4427385 ASSET_1="04427383-autoinst.xml" YAML_TEST_DATA=test_data/yast/autoyast_reinstall/autoyast_reinstall_ppc64le-hmc.yaml PRODUCTDIR="os-autoinst-distri-opensuse/products/sle"</code></p>
<p>If the above command is used without the PRODUCTDIR specification, the variable gets the value "os-autoinst-distri-opensuseos-autoinst-distri-opensuse/products/sle" which leads to test failure as here:<br>
<a href="https://openqa.suse.de/tests/4482090" class="external">https://openqa.suse.de/tests/4482090</a></p>
<p>The particular test suite runs for ppc64le-2g, ppc64le-hmc-single-disk, 64bit, s390x and aarch64. For both the ppc machines, the PRODUCTDIR needs to be set manually. For rest of them, it's not necessary.</p>
<p>I have unsuccessfully tried to reproduce the issue with other jobs on ppc.</p>