action #88834
closed[qe-core][qem] test fails in update_install
0%
Description
Observation¶
openQA test in scenario sle-12-SP3-Server-DVD-Incidents-Install-x86_64-qam-incidentinstall@64bit fails in
update_install
Test suite description¶
Incident Installation TEST
MAX_JOB_TIME=9000 due to long texlive update
Reproducible¶
Fails since (at least) Build :18008:pdsh (current job)
Expected result¶
Last good: :18231:kiwi (or more recent)
Further details¶
Always latest result in this scenario: latest
The test case is incorrect:
'zypper -n in -l pdsh pdsh-machines pdsh-slurm_18_08 pdsh-genders pdsh-dshgroup pdsh-netgroup pdsh-slurm_20_02 pdsh-slurm'
pdsh-slurm_18_08, pdsh-slurm_20_02 and pdsh-slurm cannot be installed together.
The version of pdsh-slurm needs to match the version of slurm!
Therefore, when installing slurm_20_02, pdsh-slurm_20_02 needs to be picked - likewise, for slurm_18_08, pick pdsh-slurm_18_08.
Updated by tjyrinki_suse almost 4 years ago
- Subject changed from test fails in update_install to [qe-core][qem] test fails in update_install
- Start date deleted (
2021-02-19)
Updated by zluo over 3 years ago
- Status changed from Workable to In Progress
- Assignee set to zluo
take over to check this issue.
Updated by zluo over 3 years ago
- Status changed from In Progress to Rejected
I cannot reproduce this issue anymore. It looks also good on OSD since 2 months. I think the updated packages are so different and we have to rely on packages or dependency anyway which defined in package. We have still some issue for the test module, but they are different issues.
Updated by szarate over 3 years ago
- Target version changed from Ready to QE-Core: Ready
Updated by eeich over 3 years ago
Before rejecting it I would have suggested to look what script has generated the command line:
zypper -n in -l pdsh pdsh-machines pdsh-slurm_18_08 pdsh-genders pdsh-dshgroup pdsh-netgroup pdsh-slurm_20_02 pdsh-slurm
and what caused pdsh-slurm_18_08 and pdsh-slurm_20_02 to be combined together.
A version upgrade of Slurm components needs to follow a certain process otherwise zypper will throw error messages as seen.
I'm not satisfied that this ticket gets rejected with the explanation 'we cannot reproduce the error any more' as the zypper command like mentioned above is clearly wrong. So unless another change has fixed this, there is no reason to believe that this is really fixed.