Project

General

Profile

Actions

action #117535

closed

coordination #116680: [Epic] Move test suites to PowerVM in YaST group

Remove duplicity of test suites running in PowerKVM and PowerVM in YaST job group

Added by JERiveraMoya over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2022-10-04
Due date:
% Done:

0%

Estimated time:

Description

Motivation

Main motivation is having all the test suite in YaST job group using PowerVM. In this case we cover to avoid running twice the same test suite in PowerVM and PowerKVM. This are the test suites in PowerKVM where this situation happens:

  • select_modules_and_patterns+registration
  • skip_registration, it has an unfortunate dependency with another test suite in Functional job group, QE Core should create AutoYaST to run this. Please, break this dependency notifying via MR (removing 'START_AFTER_TEST') to QE Core.
  • RAID{0,1,10,5,6}
  • activate_encrypted_volume+force_recompute
  • activate_encrypted_volume+import_users
  • addon_extensions_http_ftp
  • btrfs+warnings
  • create_hdd_transactional_server
  • cryptlvm
  • cryptlvm+cancel_existing
  • guided_btrfs
  • guided_ext4
  • guided_xfs
  • installer_extended
  • lvm
  • lvm+cancel_existing_cryptlvm
  • lvm-encrypt-separate-boot
  • lvm-full-encrypt
  • minimal+base_yast
  • minimal+role_minimal
  • msdos
  • select_disk
  • select_modules_and_patterns
  • textmode
  • transactional_server_helper_apps
  • transactional_server_snapper
  • yast2_cmd
  • yast2_ncurses_textmode
  • yast_no_self_update
  • yast_self_update

Acceptance criteria

AC1: Not run the test suite specified above as they have already an equivalent for PowerVM
AC2: Update openQA setting START_AFTER_TEST in all the required places to avoid linking the test with test suites we plan to delete.


Related issues 1 (0 open1 closed)

Related to openQA Tests - action #119629: [qe-core][functional][sle15sp5]test fails in zypper_in, sporadic issue due to command timeoutResolveddvenkatachala2022-10-31

Actions
Actions #1

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #2

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #3

Updated by coolgw over 1 year ago

skip_registration, it has an unfortunate dependency with another test suite in Functional job group, QE Core should create AutoYaST to run this. Please, break this dependency notifying via MR (removing 'START_AFTER_TEST') to QE Core.
[GW]: I have not see any START_AFTER_TEST for skip_registration such as https://openqa.suse.de/tests/9678716#dependencies, also i found we already have test case work in powervm such as https://openqa.suse.de/tests/9678705#step/bootloader_start/7, so for skip_registration, we just need remove kvm test case, no any action on "break this dependency notifying via MR".

Actions #4

Updated by JERiveraMoya over 1 year ago

  • Tags deleted (qe-yast-refinement)
  • Status changed from New to Workable

the dependency is with minimal+proxy_SCC-postreg_SUSEconnect@ppc64le:
https://openqa.suse.de/tests/9757501#dependencies

Actions #5

Updated by zoecao over 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to zoecao
Actions #6

Updated by zoecao over 1 year ago

@JERiveraMoya, I want to confirm with you that the case [skip_registration@ppc64le] is duplicated with case [select_modules_and_patterns+registration@ppc64le-hmc-single-disk], so need to remove the case of skip_registration@ppc64le, but a [3rd case minimal+proxy_SCC-postreg_SUSEconnect@ppc64le ] dependent on skip_registration@ppc64le, if I remove it directly (and the setting of START_AFTER_TEST in the 3rd case), I think the 3rd case can not run because the system created on START_AFTER_TEST won't be created, right? I should convert the 3rd (minimal+proxy_SCC-postreg_SUSEconnect@ppc64le) case to powerVM, right?

Actions #7

Updated by JERiveraMoya over 1 year ago

zoecao wrote:

@JERiveraMoya, I want to confirm with you that the case [skip_registration@ppc64le] is duplicated with case [select_modules_and_patterns+registration@ppc64le-hmc-single-disk], so need to remove the case of skip_registration@ppc64le, but a [3rd case minimal+proxy_SCC-postreg_SUSEconnect@ppc64le ] dependent on skip_registration@ppc64le, if I remove it directly (and the setting of START_AFTER_TEST in the 3rd case), I think the 3rd case can not run because the system created on START_AFTER_TEST won't be created, right? I should convert the 3rd (minimal+proxy_SCC-postreg_SUSEconnect@ppc64le) case to powerVM, right?

skip_registration and select_modules_and_patterns+registration are different test cases, they select different product modules:
https://openqa.suse.de/tests/9823486#step/select_module_desktop/1 vs https://openqa.suse.de/tests/9831515#step/select_nonconflicting_modules/1

Yes, for the other case you can communicate via MR as described in the description "Please, break this dependency notifying via MR (removing 'START_AFTER_TEST') to QE Core." Which means that this test case would fail and in the review you could also suggest to disable the scenario that will not run, but they should handle it.

Actions #8

Updated by zoecao over 1 year ago

JERiveraMoya wrote:

zoecao wrote:

@JERiveraMoya, I want to confirm with you that the case [skip_registration@ppc64le] is duplicated with case [select_modules_and_patterns+registration@ppc64le-hmc-single-disk], so need to remove the case of skip_registration@ppc64le, but a [3rd case minimal+proxy_SCC-postreg_SUSEconnect@ppc64le ] dependent on skip_registration@ppc64le, if I remove it directly (and the setting of START_AFTER_TEST in the 3rd case), I think the 3rd case can not run because the system created on START_AFTER_TEST won't be created, right? I should convert the 3rd (minimal+proxy_SCC-postreg_SUSEconnect@ppc64le) case to powerVM, right?

skip_registration and select_modules_and_patterns+registration are different test cases, they select different product modules:
https://openqa.suse.de/tests/9823486#step/select_module_desktop/1 vs https://openqa.suse.de/tests/9831515#step/select_nonconflicting_modules/1

Yes, for the other case you can communicate via MR as described in the description "Please, break this dependency notifying via MR (removing 'START_AFTER_TEST') to QE Core." Which means that this test case would fail and in the review you could also suggest to disable the scenario that will not run, but they should handle it.

Yes, I linked a wrong case link there, they are different test cases.
I have contacted with core team member Richard Fan that I'm going to remove the case of [skip_registration] and the [case] in Functional group will be influenced, he will pay attention to it and will raise the issue in the team.

Actions #10

Updated by rfan1 over 1 year ago

  • Related to action #119629: [qe-core][functional][sle15sp5]test fails in zypper_in, sporadic issue due to command timeout added
Actions #11

Updated by zoecao over 1 year ago

  • Status changed from In Progress to Resolved

MR is merged, so close here, thanks.

Actions

Also available in: Atom PDF