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 #157156 (Resolved): Textmode auto-installation fails in spvm due to partitioning ...https://progress.opensuse.org/issues/1571562024-03-13T12:43:21Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Scope"></a>
<h2 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h2>
<p>Recently the PPC grenache worker was restored and ppc tests run again. For <a href="https://openqa.suse.de/tests/13768555#step/bootloader_start/43" class="external">create_hdd_gnome</a> though, we see constant failures at the early step of bootloader_start module. The <a href="https://openqa.suse.de/tests/13711494" class="external">create_hdd_textmode</a> test is successful, following the same steps. Noticable difference so far at lsblk step, the sda disk seems not to be empty and unformatted: <a href="https://openqa.suse.de/tests/13768555#step/bootloader_start/39" class="external">https://openqa.suse.de/tests/13768555#step/bootloader_start/39</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li>Find the root cause.</li>
<li>Implement a fix, if possible.</li>
</ul>
qe-yam - action #156157 (Resolved): Add s390x slem migration test 5.5->6.0https://progress.opensuse.org/issues/1561572024-02-27T14:32:39Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Add a migration test for slem 5.5 to 6.0 for s390x arch, that will use a new flavor than default , as this one does not contain the s390x arch.</p>
qe-yam - action #155758 (Resolved): [sporadic] Reboot takes too long for ppc64lehttps://progress.opensuse.org/issues/1557582024-02-21T14:12:30Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>For some ppc tests, we experience a sporadic reboot failure on different points of the test. As the failure doesn't happen every time on the same point, it could be an infrastructure issue that might be fixed by increasing the timeout.</p>
<p>Failure examples:<br>
<a href="https://openqa.suse.de/tests/13549614#next_previous" class="external">https://openqa.suse.de/tests/13549614#next_previous</a><br>
<a href="https://openqa.suse.de/tests/13554127#next_previous" class="external">https://openqa.suse.de/tests/13554127#next_previous</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Check if the ppc failures can go away by increasing the reboot timeout for ppc64le.</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<ul>
<li>In case the issue persists, check if it could be a bug.</li>
<li>In case there are no indications of a bug, ask tools team for more information
note: not sure how this two suggestions above could go, as power kvm is not officially supported and tools squad is not taking care of exotic architecture.
Most likely if unstable it is better to consider disabling the scenario, we'll see...</li>
</ul>
qe-yam - action #155638 (Resolved): Investigate if ppc create_hdd tests work with current setuphttps://progress.opensuse.org/issues/1556382024-02-19T13:19:15Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Currently we have a succession of depended ppc64le-4g tests:<br>
<a href="https://openqa.suse.de/tests/13393487#dependencies" class="external">https://openqa.suse.de/tests/13393487#dependencies</a><br>
These tests have been failing for the last 3 builds as the create_hdd_gnome_libyui test is failing : <a href="https://openqa.suse.de/tests/13494498#next_previous" class="external">https://openqa.suse.de/tests/13494498#next_previous</a> due to missing image from parent test: create_hdd_gnome</p>
<p><strong>Acceptance Criteria</strong></p>
<ul>
<li>Conclude if the test succession is worth keeping for the particular arch</li>
<li>Investigate if the chain of tests can work with current ppc64le-4g workers</li>
<li>Check if the parent test create_hdd should be replaced by the existing autoyast one as occurred with other archs </li>
</ul>
qe-yam - action #154753 (Resolved): [sporadic] Make stable validate_lvm_raid1 reboothttps://progress.opensuse.org/issues/1547532024-02-01T14:17:37Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p><a href="https://openqa.suse.de/tests/13402260/modules/validate_lvm_raid1/steps/62" class="external">validate_lvm_raid1</a> test for x86_64 fails sporadically during reboot, as it is expected to see textmode linux login but the loading screen is taking too long.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>The failure rate is about 8/10 test runs with increased bootloader timeout (see : <a href="https://github.com/sofiasyria/os-autoinst-distri-opensuse/blob/589791e625851f5227063559107c9c45e004a34b/tests/console/validate_lvm_raid1.pm#L30" class="external">https://github.com/sofiasyria/os-autoinst-distri-opensuse/blob/589791e625851f5227063559107c9c45e004a34b/tests/console/validate_lvm_raid1.pm#L30</a> )<br>
and 2/10 with increased QEMURAM=2048 </p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: The test should not fail at all.</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>Last good: <a href="https://openqa.suse.de/tests/13373530" class="external">50.1</a> (or more recent)<br>
Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=lvm%2BRAID1&version=15-SP6" class="external">latest</a></p>
qe-yam - action #154729 (Resolved): Adapt skip_registration in maintenance job grouphttps://progress.opensuse.org/issues/1547292024-02-01T10:57:33Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>It seems that we interact too fast on the screen with libyui-rest-api creating this issues found in new test suite enabled recently in maintenance updates: <a href="https://openqa.suse.de/tests/13406835#step/select_module_desktop/1" class="external">https://openqa.suse.de/tests/13406835#step/select_module_desktop/1</a><br>
the event ui dispatcher should have given us some clue but we missed as libyui-rest-api doesn't have any trouble.<br>
We need to ensure that we are in the right screen interacting and select desktop.</p>
<p>In SP5 a bug needs to be filed because it is a different error in the same place:<br>
<a href="https://openqa.suse.de/tests/13406901#step/select_module_desktop/1" class="external">https://openqa.suse.de/tests/13406901#step/select_module_desktop/1</a><br>
(please, add the bug here or as a comment when filed)</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>SLE 15 SP3 (but potentially SP5 if the bug is fixed as we might expect same situation).</p>
<p>At the moment we have moved this test suite to dev group to not block maintenance updates:<br>
<a href="https://gitlab.suse.de/qe-yam/openqa-job-groups/-/merge_requests/59" class="external">https://gitlab.suse.de/qe-yam/openqa-job-groups/-/merge_requests/59</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Test suite for skip_registration scenario which test self_update for the installer itself is enable back in prod job group (for SLE 15 SP3,and potentially SP5).<br>
<strong>AC2</strong>: Only is enabled there if it is passing and stable.</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>If for SP5 the problem is not fixed, please file follow-up ticket.<br>
<a href="https://suse.slack.com/archives/C02CCRM8946/p1706532832696779" class="external">https://suse.slack.com/archives/C02CCRM8946/p1706532832696779</a></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 #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 #154690 (Resolved): Apply the glitch workaround in yast2_securityhttps://progress.opensuse.org/issues/1546902024-02-01T08:48:33Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>The module fails due to the yast2 window not being properly refreshed and show the content. We can apply the existing workaround to avoid future failures. See <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/YaST/workarounds.pm#L37" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/YaST/workarounds.pm#L37</a></p>
<p>openQA test in scenario sle-15-SP6-Online-x86_64-yast2_gui@svirt-xen-hvm fails in<br>
<a href="https://openqa.suse.de/tests/13401911/modules/yast2_security/steps/10" class="external">yast2_security</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: After applying the workaround the module stable (10x verifications at least).</p>
qe-yam - action #154687 (Resolved): Confirm worker changes in accept_default_part_scheme and appl...https://progress.opensuse.org/issues/1546872024-02-01T08:26:38Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>The particular test module is supposed to select sda disk for root partition. This used to be an adequate solution as the disk naming for virt-mm-64bit-ipmi worker_class SUTs was stable. Lately this has changed and we see SUTs with sda being too small for a root partition or no sda at all. </p>
<p>openQA test in scenario sle-15-SP6-Online-x86_64-guided_btrfs@virt-mm-64bit-ipmi fails in<br>
<a href="https://openqa.suse.de/tests/13394667/modules/accept_default_part_scheme/steps/2" class="external">accept_default_part_scheme</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Verify with infra/Yast/kernel team what is the expected naming for the particular arch.<br>
<strong>AC2</strong>: Depending on AC1, adjust the test to select the biggest enough disk</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>Try to avoid to create complex logic to select the biggest disk, perhaps a regex (sdb|sdc) is enough and we can search the UI element with libyui-rest-api with that.</p>
qe-yam - action #154462 (Resolved): test fails in iscsi_server because the LUN path is not typedhttps://progress.opensuse.org/issues/1544622024-01-29T13:11:27Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>The test is supposed to enter a LUN path (see 15SP5 last successful run: <a href="https://openqa.suse.de/tests/11164042#step/iscsi_server/60" class="external">https://openqa.suse.de/tests/11164042#step/iscsi_server/60</a> )<br>
but it leaves it empty, pressing alt-o (OK) and the yast module complains about empty LUN path causing the test to fail. In the autoinst.log we can see that the module attempts to fill up the LUN path :</p>
<p>[2024-01-29T12:53:36.749985+01:00] [debug] [pid:106945] tests/iscsi/iscsi_server.pm:220 called iscsi_server::target_backstore_tab -> tests/iscsi/iscsi_server.pm:187 called utils::type_string_slow_extended -> lib/utils.pm:459 called testapi::type_string<br>
[2024-01-29T12:53:36.750242+01:00] [debug] [pid:106945] <<< testapi::type_string(string="/root/iscsi-disk", max_interval=13, wait_screen_change=0, wait_still_screen="0.05", timeout=5, similarity_level=38)<br>
[2024-01-29T12:53:41.735292+01:00] [debug] [pid:106945] tests/iscsi/iscsi_server.pm:220 called iscsi_server::target_backstore_tab -> tests/iscsi/iscsi_server.pm:187 called utils::type_string_slow_extended -> lib/utils.pm:459 called testapi::type_string<br>
[2024-01-29T12:53:41.735582+01:00] [debug] [pid:106945] <<< testapi::wait_still_screen(timeout=5, similarity_level=38, stilltime="0.05")</p>
<p>The test must be adjusted in order to successfully enter the LUN path and proceed.</p>
<p>Also affecting tests: iscsi_server_normal_auth_backstore_hdd and iscsi_server_normal_auth_backstore_lvm</p>
<p>openQA test in scenario sle-15-SP6-Online-x86_64-iscsi_server_normal_auth_backstore_fileio@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13373522/modules/iscsi_server/steps/62" class="external">iscsi_server</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Make reliable the step mentioned above to fill the LUN path.</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>