action #107311
closed
coordination #103962: [saga][epic] Easy multi-machine handling: MM-tests as first-class citizens
coordination #15850: [epic] Improve displaying job dependencies
The dependency tree of `openqa-clone-job --clone-children` is broken
Added by ph03nix about 2 years ago.
Updated about 2 years ago.
Category:
Regressions/Crashes
Description
Observation¶
Then cloning a job with children using openqa-clone-job --clone-children ... the resulting dependency tree is not identical to the original tree.
Steps to reproduce¶
openqa-clone-job --host http://duck-norris.qam.suse.de --clone-children --skip-download https://openqa.suse.de/tests/8215448 HDD_1=publiccloud_tools_0027.qcow2- Compare the dependency tree of the original job vs the cloned job.
Problem¶
- Dependency tree is not identical
Suggestion¶
Workaround¶
Files
- File Screenshot 2022-02-23 at 09-27-55 openQA sle-15-SP3-AZURE-BYOS-Updates-x86_64-Build20220223-1-publiccloud_download_testrepo[...].png added
- File Screenshot 2022-02-23 at 09-27-46 phoenix_-openQA server sle-15-SP3-AZURE-BYOS-Updates-x86_64-Build20220223-1-publiccloud_d[...].png added
- File deleted (
Screenshot 2022-02-23 at 09-27-46 phoenix_-openQA server sle-15-SP3-AZURE-BYOS-Updates-x86_64-Build20220223-1-publiccloud_d[...].png)
- File deleted (
Screenshot 2022-02-23 at 09-27-55 openQA sle-15-SP3-AZURE-BYOS-Updates-x86_64-Build20220223-1-publiccloud_download_testrepo[...].png)
Screenshot of the original dependency tree:
Screenshot of the resulting dependency tree:
- Related to action #69976: Show dependency graph for cloned jobs added
- Assignee set to mkittler
- Priority changed from Normal to High
- Target version set to Ready
Sounds like a recent regression. @mkittler please look into this.
I can reproduce the problem locally. However, I'd like to note that I only changed displaying the tree. So https://github.com/os-autoinst/openQA/pull/4507 shouldn't affect cloning. It only changes the functions used to make the JSON data for the graph rendering library, not the cluster computation. Maybe it is caused by https://github.com/os-autoinst/openQA/pull/4498 as it also changes the cluster computation or the problem was even introduced quite a while ago when changing some logic within the clone script.
This issue is already present for a long time*, this is not something that has been introduced recently.
- out of my head - more than a year, I also remember other colleagues to complain about this issue
- Status changed from New to In Progress
This issue is already present for a long time*, this is not something that has been introduced recently.
I can only concur. I've just cloned the dependency tree again and fixed it afterwards via a manual SQL query. This allows me to clone the "good" graph from my local instance to my local instance. So I can control the openQA version on both ends. The problem was reproducible on 633b6df5b which was before my recent dependency changes.
I will of course nevertheless try to fix it. As far as I can see (via some debug printing), openQA's API returns correct cluster information. So the bug is entirely within the clone script.
- Parent task set to #15850
- Due date set to 2022-03-10
Setting due date based on mean cycle time of SUSE QE Tools
- Related to deleted (action #69976: Show dependency graph for cloned jobs)
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
The PR has been merged and is deployed on OSD. (The deployment on OSD doesn't really matter as the fix is specific to the local openqa-clone-job script.)
- Due date deleted (
2022-03-10)
Also available in: Atom
PDF