action #158553
closed[tools] test fails in openqa_worker trying to download rpm files from devel:openQA ending in HTTP error 404 despite retries
0%
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
Updated by openqa_review 8 months ago
- Due date set to 2024-04-23
Setting due date based on mean cycle time of SUSE QE Tools
Updated by livdywan 8 months ago
- Status changed from In Progress to Feedback
livdywan wrote in #note-1:
The openqa_worker module uses retry/zypper with 7 retries and exponential backoff so maybe the same is worth using here?
Going one step further and attempting to consolidate package installs since it would be nice if we didn't need to add yet another retry for every single case we run into.
https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/170
Updated by livdywan 8 months ago
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
Updated by livdywan 8 months ago
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.
Updated by livdywan 8 months ago
- Status changed from Feedback to Resolved
Going one step further and attempting to consolidate package installs since it would be nice if we didn't need to add yet another retry for every single case we run into.
https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/170
Both merged. Jobs in production look good.