action #158553
closed
[tools] test fails in openqa_worker trying to download rpm files from devel:openQA ending in HTTP error 404 despite retries
Added by okurz about 1 month ago.
Updated 28 days ago.
Category:
Regressions/Crashes
Description
Observation¶
openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install_nginx@64bit-2G fails in
openqa_worker
trying to download from devel:openQA ending in HTTP error 404 despite retries
Reproducible¶
Fails since (at least) Build :TW.27699 (current job)
but failed at least 3 times during the same time window
Expected result¶
Last good: :TW.27698 (or more recent)
Further details¶
Always latest result in this scenario: latest
- Status changed from New to In Progress
- Assignee set to livdywan
- Due date set to 2024-04-23
Setting due date based on mean cycle time of SUSE QE Tools
- Status changed from In Progress to Feedback
New idea. Maybe we can use this to avoid having to ref in every single place?
##
## Amount of time in minutes that must pass before another refresh.
##
## Valid values: Integer
## Default value: 10
##
## If you have autorefresh enabled for a repository, it is checked for
## up-to-date metadata not more often than every <repo.refresh.delay>
## minutes. If an automatic request for refresh comes before <repo.refresh.delay>
## minutes passed since the last check, the request is ignored.
##
## A value of 0 means the repository will always be checked. To get the opposite
## effect, disable autorefresh for your repositories.
##
## This option has no effect for repositories with autorefresh disabled, nor for
## user-requested refresh.
##
# repo.refresh.delay = 10
Also to mention here, I got some input from the zypper devs. Unfortunately it seems the retry ref/in pattern is the most practical option right now - internally zypper can't refresh the metadata again short of forking itself as a work-around, and improvements to the architecture take time due to ABI compatibility requirements.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF