action #117532
closed
coordination #116680: [Epic] Move test suites to PowerVM in YaST group
Adapt/Remove test suites in YaST group in order to use PowerVM
Added by JERiveraMoya over 1 year ago.
Updated over 1 year ago.
Description
Motivation¶
With the goal of making more robust testing and only test in ppc64le where is supported, in this case with virtualization PowerVM, we could tackle in this ticket the following test suites:
- mediacheck (Online & Full mediums)
- releasenotes_origin+unregistered
- textmode_installation_minimal_role
- gpt
- lvm_multipath
- lvm_multipath_encrypted
- multipath
- yast2_nfs_v{3,4}_{client,server}
- yast_hostname
- yast_hostname+dhcp_hostname
- yast_hostname+linuxrc_hostname
Acceptance criteria¶
AC1: Adapt/Remove test suites listed above in YaST group to use PowerVM following the suggestions indicated below
Suggestions¶
- We will prabably need to remove testsuite mediacheck for ppc64le (Full + Online), as requires OFW parameter to work, and the image seems that is fetched from url in PowerVM.
- Regarding releasenotes_origin+unregistered we should see if makes sense to check them in the existing way.
- For textmode_installation_minimal_role will be using the existing test modules for libyui-rest-api in order to replace needle-based test modules.
- For gpt we are not going to have images with 17 TeraBytes in the worker, so we can remove this one.
- Regarding lvm_multipath, lvm_multipath_encrypted and multipath there is not multipath (just check Kernel job group) enabled for virtualization PowerVM, so we can proceed to remove them.
- We will be removing yast2_nfs_v{3,4}_{client,server} due there there is not MultiMachine with PowerVM.
- For yast_hostname_* we don't run these test suites for remote workers, so we can remove it as well.
- Description updated (diff)
- Subject changed from Adapt test suites in YaST group to use PowerVM to Adapt/Remove test suites in YaST group in order to use PowerVM
- Description updated (diff)
I prefer keep test cases which can not handled by PowerVM setup, at least we can use powerkvm do some software level check. such as:
1)Regarding lvm_multipath, lvm_multipath_encrypted and multipath there is not multipath (just check Kernel job group) enabled for virtualization PowerVM, so we can proceed to remove them.
2)We will be removing yast2_nfs_v{3,4}_{client,server} due there there is not MultiMachine with PowerVM.
as requires OFW parameter to work
What is OFW parameter?
coolgw wrote:
I prefer keep test cases which can not handled by PowerVM setup, at least we can use powerkvm do some software level check. such as:
1)Regarding lvm_multipath, lvm_multipath_encrypted and multipath there is not multipath (just check Kernel job group) enabled for virtualization PowerVM, so we can proceed to remove them.
2)We will be removing yast2_nfs_v{3,4}_{client,server} due there there is not MultiMachine with PowerVM.
For me it is no-go to use virtualization that is not supported, recently I got another progress report with some slow registration process and it is a waste of time to go forward with that with bugs or anything, I believe we can drop test coverage there, if you find a multipath bug you will notice that the developers are not going to fix it or at least it is not going to happen anytime soon and will probably ask you to reproduce it in a strange way, not using openQA.
We should spend some time to investigate how those test cases could be done in PowerVM rather than wasting time with unsupported virtualization, wdyt?
Just for clarification, when we say PowerVM we are talking about the pvm-hmc backend in openQA.
geor wrote:
Just for clarification, when we say PowerVM we are talking about the pvm-hmc backend in openQA.
yes, that one.
JERiveraMoya wrote:
coolgw wrote:
I prefer keep test cases which can not handled by PowerVM setup, at least we can use powerkvm do some software level check. such as:
1)Regarding lvm_multipath, lvm_multipath_encrypted and multipath there is not multipath (just check Kernel job group) enabled for virtualization PowerVM, so we can proceed to remove them.
2)We will be removing yast2_nfs_v{3,4}_{client,server} due there there is not MultiMachine with PowerVM.
For me it is no-go to use virtualization that is not supported, recently I got another progress report with some slow registration process and it is a waste of time to go forward with that with bugs or anything, I believe we can drop test coverage there, if you find a multipath bug you will notice that the developers are not going to fix it or at least it is not going to happen anytime soon and will probably ask you to reproduce it in a strange way, not using openQA.
We should spend some time to investigate how those test cases could be done in PowerVM rather than wasting time with unsupported virtualization, wdyt?
If case can pass, i think we can keep it since
1) no any extra effort needed, so no wast any time
2) provide confidence on test coverage
if case start fail, remove it and we can start open new tickets how to check
- Tags deleted (
qe-yast-refinement)
- Description updated (diff)
- Status changed from New to Workable
let's agree on that then and see how it goes, but I would request to add in the description of the test suite only for ppc64le pksome informative message to follow "if case start fail, remove it and we can start open new tickets how to check" otherwise more ticket will enter our queue and we might forget.
- Status changed from Workable to In Progress
- Assignee set to leli
releasenotes_origin+unregistered:
It seems send_key('ctrl-shift-alt-x'); but no xterm started, I think the key maybe changed to open xterm on power VM.
https://openqa.nue.suse.com/tests/9806519#step/release_notes_from_url/3
#################################################
I use developer mode to try to reproduce this issue but failed, I can send key 'ctrl-shift-alt-x' and got the xterm dialog, so this should be a test issue, I will try to add some sleep before sending the key to have a look.
JERiveraMoya wrote:
leli wrote:
Switch to install shell and create new needles then the release_notes_from_url issue gone, but now it failed here:
http://openqa.nue.suse.com/tests/9849587#step/validate_default_target/6
It seems the system target changed on power VM.
yes, expected, powerVM doesn't have desktop.
So need create a new yaml file for this test on powerVM? Cause the schedule/yast/releasenotes_origin+unregistered.yaml have desktop selected. Or just remove this case?
leli wrote:
JERiveraMoya wrote:
leli wrote:
Switch to install shell and create new needles then the release_notes_from_url issue gone, but now it failed here:
http://openqa.nue.suse.com/tests/9849587#step/validate_default_target/6
It seems the system target changed on power VM.
yes, expected, powerVM doesn't have desktop.
So need create a new yaml file for this test on powerVM? Cause the schedule/yast/releasenotes_origin+unregistered.yaml have desktop selected. Or just remove this case?
Created a new yaml to skip select module and select textmode role, pass now, http://openqa.nue.suse.com/tests/9869911#
- Description updated (diff)
- Status changed from In Progress to Resolved
Also available in: Atom
PDF