action #111016
Updated by JERiveraMoya over 1 year ago
#### 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 want to get rid off PowerKVM scenario, PowerKVM, 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. All archs and backends, but **discard ppc64le (PowerKVM)** 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 https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=&modules=yast2_kdump&module_re=&distri=sle&version=15-SP5&build=24.1&groupid=129 #### Acceptance criteria #### **AC1**: Create new test suite for kdump **AC2**: Provide easy distintion of libyui code and other code, like pre-requirement of installed packages/product modules and post-requirements **AC3**: Interact with yast2 kdump via libyui rest api **AC4**: There are not if/else (conditional logic) on the design of this new test. **AC5**: 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. 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`. 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.