QA » openQA Project » openQA Tests » qe-yam

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.