action #111016

Updated by JERiveraMoya almost 2 years ago

#### Motivation #### 
 Motivated by this discussion: 
 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. 
 All archs and backends, but **discard ppc64le (PowerKVM)** 

 #### 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: 
 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 test itself should not test the default for kdump enabled or disabled default, that can be done separately, so our first method in a separate test module (out of the scope of this task) and should controller could be done in the command line. 
 - In order to `ensure_kdump_enabled` which will enable kdump when it if it is needed for corresponding arch/backend we will create test module `enable_kdump`. not yet enabled. 
 - Create new test module `accept_kdump_options` with Controller method `accept_kdump_options`. 
 - For activating firmware kdump we will the best option IMO is to have a separate test module schedule, `ensure_kdump_enable` and `use_firmware_assisted_dump` being scheduled the later only schedule for spvm before `accept_kdump_options`. spvm. 
 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.