Project

General

Profile

Actions

action #111016

closed

coordination #121885: [epic] Enable libyui-rest-api for YaST modules

Create new test suite and test modules to interact with yast2 kdump using libyui REST

Added by JERiveraMoya almost 2 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2022-05-12
Due date:
% Done:

0%

Estimated time:

Description

Motivation

Motivated by this discussion:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/14887
yast2 kdump seems to be a good candidate to use libyui rest api.
In previous task we have seen how tricky is the logic with popup that open or not sometimes.
A better design will help here in the future.

But also notice that we recently got rid off PowerKVM scenario, so we don't need to deal with the logic of the pop-up not showing.
The other differences between archs/backends are:

  • For qemu, we have kdump disabled and we need to enable it.
  • For s390 kvm and spvm we have kdump enabled.
  • For spvm we need to mark firmware-assistant dump.

Scope

Affects module yast2_kdump in testsuite yast2_ncurses_textmode.
Limited to SLE 15-SP5 Online medium in YaST job group.

https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=&modules=yast2_kdump&module_re=&distri=sle&version=15-SP5&build=38.1&groupid=129

Acceptance criteria

AC1: Provide easy distinction of libyui code and other code, like pre-requirement of installed packages/product modules and post-requirements
AC2: Interact with yast2 kdump via libyui rest api
AC3: There are not if/else (conditional logic) on the design of this new test.
AC4: Popup reboot message is developed separately, not as part of StartUpPage.

Additional information

Takes as example how to design and map the screen: #113492

Documentation about kdump: https://documentation.suse.com/sles/15-SP4/html/SLES-all/cha-tuning-kexec.html
As you can see, it is kind of under-tested so, to have a new test suite might be a good idea, so we can extend it.

Provide 'easy distinction' means that initial installation of packages/product modules and its later de-installation IMO should be encapsulated in 2 different test modules respectively.
libyui rest code should be "the protagonist", just include the opening and the close of the YaST module and in the middle all the important actions.

How to avoid conditional logic if we have differences among architectures? (just IMO, comparing the solution with different schedules vs different test data):

  • Test the default for kdump enabled or disabled can be done in a separate test module (out of the scope of this task) and should be done in the command line.
  • In order to enable kdump when is needed for corresponding arch/backend we will create test module enable_kdump.
  • Create new test module accept_kdump_options with Controller method accept_kdump_options.
  • For activating firmware kdump we will have a separate test module use_firmware_assisted_dump being scheduled only for spvm before accept_kdump_options.

Notice that solution with test data to be used as input to the screen is not really transparent, it is easy to not see at first view what the test does different, besides it requires to pass to some common function enable_kdump a parameter coming from test data related with firmware and if it is filled in, tick the box, it saves files but it is more obscure though. The preference is to split in different test module as described above.

Actions #1

Updated by JERiveraMoya almost 2 years ago

  • Priority changed from Normal to Low
Actions #2

Updated by JERiveraMoya over 1 year ago

  • Tags changed from YaST to qe-yast-refinement
  • Subject changed from Improve yast2 kdump to Improve yast2 kdump using libyui REST
  • Description updated (diff)
  • Priority changed from Low to Normal
Actions #3

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #4

Updated by JERiveraMoya over 1 year ago

  • Subject changed from Improve yast2 kdump using libyui REST to Create new test module to interact with yast2 kdump using libyui REST
Actions #5

Updated by rainerkoenig over 1 year ago

From my understanding that ticket would require:

  • building a yast_kdump_controller and yast_kdump_page package that implentes libyui routines.
  • splitting up the existing yast_kdump test module so that we handle installation of kdump and yast2-kdump in an own test module and also the communciation with the controller in an own test module.
  • check what we need to do with the old kdump_utils package, if no one uses this after the transformation we could delete it.
Actions #6

Updated by geor over 1 year ago

  • Description updated (diff)

I just clarified scope a bit, hope it helps.

Actions #7

Updated by geor over 1 year ago

  • Description updated (diff)
Actions #8

Updated by JERiveraMoya over 1 year ago

  • Priority changed from Normal to Low
Actions #9

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #10

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #11

Updated by JERiveraMoya over 1 year ago

  • Subject changed from Create new test module to interact with yast2 kdump using libyui REST to Create new test suite and test module to interact with yast2 kdump using libyui REST
  • Description updated (diff)
Actions #12

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #13

Updated by JERiveraMoya over 1 year ago

Updated with more details, to make this testing more extensible, as it is one of the yast module also working on alp.

Actions #14

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #15

Updated by JERiveraMoya over 1 year ago

  • Subject changed from Create new test suite and test module to interact with yast2 kdump using libyui REST to Create new test suite and test modules to interact with yast2 kdump using libyui REST
  • Description updated (diff)
  • Priority changed from Low to Normal
Actions #16

Updated by JERiveraMoya over 1 year ago

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

Updated by leli over 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to leli
Actions #19

Updated by JERiveraMoya about 1 year ago

  • Parent task set to #121885
Actions #20

Updated by openqa_review about 1 year ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: yast2_ncurses_textmode
https://openqa.suse.de/tests/10219045#step/yast2_kdump/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions #21

Updated by leli about 1 year ago

  • Status changed from In Progress to Resolved

PR merged, let keep an eye on the test results on next build.

Actions

Also available in: Atom PDF