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 want to get rid off 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. online medium. All archs and backends, but **discard ppc64le (PowerKVM)** backends. 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**: Provide easy distintion 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 **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 #### Documentation about kdump: https://documentation.suse.com/sles/15-SP4/html/SLES-all/cha-tuning-kexec.html Takes as example how to design and map the screen: #113492 Initial installation of package should go in one function and de-installation of those in another one. libyui rest code should be "the protagonist" on the test layer, so it can be read in a very clear way, it is that so, that usually you would not need any additional comments in your code (those normally indicate that the code is not simple enough). **How to avoid conditional logic if we have differences among architectures?** - The test itself should not test the default, that can be done separately, so our first method in controller could be `ensure_kdump_enabled` which will enable it if it is not yet enabled. - For activating firmware kdump the best option IMO is to have separate schedule, 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. For this task the functions to install and uninstall package will live in the test, so when we have a second version of it for spvm we will have to repeat that, that could be solve in the future, because as you can see the documentation, for being the preferred option for kdump, it is kind of understested, so in the future we might have a test suite dedicated for each module, when the part of installation of de-installation can be done as a separate test module. Therefore we would have two tests modules: `ensure_kdump_enable` and `use_firmware_assisted_dump` being the later only schedule for spvm. The solution with test data 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.