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 #154717 (Rejected): Adjust select_module_desktop to verify the existence of the m...https://progress.opensuse.org/issues/1547172024-02-01T09:54:50Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>The skip_registration test <a href="https://openqa.suse.de/tests/13400788#step/select_module_desktop/1" class="external">fails for 15SP3</a> because, according to the yui logs, the addon_repos widget seems to have appeared and the module proceeds to select item with value=Desktop+Applications+Module , but in reality the item is not loaded yet and this is causing the Yast error that we mistakenly regarded as a bug result ( see <a href="https://bugzilla.suse.com/show_bug.cgi?id=1219403" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1219403</a> ). </p>
<p>yui logs:<br>
[2024-01-31T23:41:26.647742+01:00] [info] [pid:29717] skip_registration test module finished<br>
[2024-01-31T23:41:26.649364+01:00] [info] [pid:29717] select_module_desktop test module started<br>
[2024-01-31T23:41:26.649764+01:00] [debug] [pid:29717] Finding widget by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:27.652241+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:29.656276+01:00] [debug] [pid:29717] Finding widget by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:30.660504+01:00] [debug] [pid:29717] Sending action to widget by url: <a href="http://localhost:39103/v1/widgets?action=check&id=addon_repos&value=Desktop+Applications+Module" class="external">http://localhost:39103/v1/widgets?action=check&id=addon_repos&value=Desktop+Applications+Module</a><br>
[2024-01-31T23:41:31.664662+01:00] [debug] [pid:29717] Finding widget by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:32.667784+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:34.672477+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:36.675976+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:38.678876+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:40.681975+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:42.685466+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<ul>
<li>Adjust the test module, in order to avoid similar failures in the future.</li>
</ul>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>The module is used in many test suites for 15-SP{3..6}.<br>
The test suite is now moved to development job group: <a href="https://openqa.suse.de/group_overview/446" class="external">https://openqa.suse.de/group_overview/446</a></p>
qe-yam - action #154183 (Rejected): Yam support images not being replaced by latest runshttps://progress.opensuse.org/issues/1541832024-01-24T14:09:51Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>While working on <a href="https://progress.opensuse.org/issues/153043" class="external">poo#153043</a> , the realization that the published images on osd are not replaced by the latest runs of teh yam support images tests occurred. This can be a problem as it invalidates all the effort of minimizing patch time.</p>
<p><strong>Acceptance criteria</strong></p>
<ul>
<li>Make sure that a test publishing an image under the same name can replace an existing one.</li>
<li>Check if the above applies for all archs.</li>
</ul>
<p>Proposal: this can be done by creating a dev job group, publish some images gnome images under a certain name and replace them with textmode images but keeping the same PUBLISH_HDD name and then proceed to see if they where replaced by booting into them (either manually or by using some other openqa test). Any other way of verification would be acceptable as well.</p>
qe-yam - action #153967 (Rejected): Check and update bugs linked with soft failures in detect_yas...https://progress.opensuse.org/issues/1539672024-01-19T13:22:49Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Currently the <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=detect_yast2_failures_dev%40sofiasyria%2Fos-autoinst-distri-opensuse%23y2log_fail&version=15-SP6" class="external">detect_yast2_failures</a> test suite is soft failing for a number of reported bugs that have beed confirmed but are idle for a long time. We should comment on each bug report to check with the developers and see if the error messages are just noise to be ignored, or we should keep the soft failure. (See example <a href="https://bugzilla.suse.com/show_bug.cgi?id=1167248#c18" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1167248#c18</a> )<br>
In case we can safely ignore the failure, it should be linked with the trello page for y2log cleanup.</p>
<p>Related ticket : <a href="https://progress.opensuse.org/issues/153085" class="external">https://progress.opensuse.org/issues/153085</a></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 #152296 (Rejected): Optimize gitlab repo CIhttps://progress.opensuse.org/issues/1522962023-12-08T12:16:45Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Currently, our <a href="https://gitlab.suse.de/qe-yam/openqa-job-groups" class="external">gitlab repo</a> for openqa job groups is running on a simple checks CI. There is a yamllint check, a check for schedule and data files existence and then the openqa-cli command that checks if it can post the job group . We should make some tests to see if the above checks provide failure and pass when expected.</p>
<p>Note: A specific scenario to look into is if we want to move a test suite to another Job group, within the repo , one MR with two commits, will it pass or will it provide error that the test suite already exists in another Job group?</p>
<p><strong>Acceptance criteria</strong></p>
<ul>
<li>Run tests for different scenarios to verify the CI functionality</li>
<li>Open follow-up tickets for any improvements if needed.</li>
</ul>
qe-yam - action #133616 (Rejected): agama full_disk_encryption and lvm tests fail due to changes...https://progress.opensuse.org/issues/1336162023-08-01T11:49:49Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>The latest changes in Agama live image is that only dolomite is available for installation, no ALM micro or server. Therefore, we need to adjust our playwright test lvm and full_disk_encryption that currently fail. The Tumbleweed test will remain as is, because tumbleweed is still available.</p>
<p><a href="https://openqa.opensuse.org/tests/overview?distri=alp&version=agama-2.1-staging&build=2.17&groupid=96" class="external">https://openqa.opensuse.org/tests/overview?distri=alp&version=agama-2.1-staging&build=2.17&groupid=96</a></p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario alp-agama-2.1-staging-agama-live-default-Playwright-x86_64-agama_dolomite_full_disk_encryption@64bit-2G fails in<br>
<a href="https://openqa.opensuse.org/tests/3470423/modules/agama_full_disk_encryption/steps/6" class="external">agama_full_disk_encryption</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>The base test suite is used for job templates defined in YAML documents. It has no settings of its own.</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.opensuse.org/tests/3468486" class="external">2.16</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.opensuse.org/tests/3457233" class="external">2.5</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.opensuse.org/tests/latest?arch=x86_64&distri=alp&flavor=agama-live-default-Playwright&machine=64bit-2G&test=agama_dolomite_full_disk_encryption&version=agama-2.1-staging" class="external">latest</a></p>
qe-yam - action #133373 (Rejected): Tidy up migration yaml job groups with yamllinthttps://progress.opensuse.org/issues/1333732023-07-26T10:24:05Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>The <a href="https://gitlab.suse.de/coolgw/wegao-test/-/tree/master/JobGroups" class="external">migration job group yamls</a>, if parsed with yamllint, show a lot of errors. It's better to tidy them up and re-order the test suites for each product and architecture according to name alphabetical order, for better readability.</p>
<p>Note: yamllint is available in opensuse repo as python311-yamllint package. Documentation <a href="https://yamllint.readthedocs.io/en/stable/" class="external">here</a></p>
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 #130360 (Rejected): addon_products_via_SCC_yast2 in SLE12SP4/5 attempts to re-reg...https://progress.opensuse.org/issues/1303602023-06-05T07:38:46Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>In Yast Maintenance Dev job group The module addon_products_via_SCC_yast2 tries to register an already registered system. We should check first the registration status and proceed if needed. </p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-12-SP5-Server-DVD-Updates-x86_64-mru-iscsi_server_normal_auth_backstore_hdd_dev@64bit fails in<br>
<a href="https://openqa.suse.de/tests/11253708/modules/addon_products_via_SCC_yast2/steps/17" class="external">addon_products_via_SCC_yast2</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>. iSCSI multimachine test suite with manually configure the static network between SUTs. Authentication: 2way normal authentication, discovery authentication is not configured Backstore: plain drive Test data are included in enclosed yaml file. </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/10991058" class="external">20230426-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=Server-DVD-Updates&machine=64bit&test=mru-iscsi_server_normal_auth_backstore_hdd_dev&version=12-SP5" class="external">latest</a></p>