From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>
Subject: Re: [PATCH 3/3] tests/functional: handle URLError when fetching assets
Date: Fri, 29 Aug 2025 10:08:12 +0100 [thread overview]
Message-ID: <aLFt_KcyYpd3CyYt@redhat.com> (raw)
In-Reply-To: <801f322a-6151-40ab-879a-f64e117d6d04@redhat.com>
On Fri, Aug 29, 2025 at 11:00:12AM +0200, Thomas Huth wrote:
> On 29/08/2025 10.31, Daniel P. Berrangé wrote:
> > We treat most HTTP errors as non-fatal when fetching assets,
> > but forgot to handle network level errors. This adds catching
> > of URLError so that we retry on failure, and will ultimately
> > trigger graceful skipping in the pre-cache task.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> > tests/functional/qemu_test/asset.py | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/functional/qemu_test/asset.py b/tests/functional/qemu_test/asset.py
> > index ae2bec3ea5..36f64fe2f6 100644
> > --- a/tests/functional/qemu_test/asset.py
> > +++ b/tests/functional/qemu_test/asset.py
> > @@ -15,7 +15,7 @@
> > from time import sleep
> > from pathlib import Path
> > from shutil import copyfileobj
> > -from urllib.error import HTTPError
> > +from urllib.error import HTTPError, URLError
> > class AssetError(Exception):
> > def __init__(self, asset, msg, transient=False):
> > @@ -171,6 +171,13 @@ def fetch(self):
> > raise AssetError(self, "Unable to download %s: "
> > "HTTP error %d" % (self.url, e.code))
> > continue
> > + except URLError as e:
> > + # This is typically a network/service level error
> > + # eg urlopen error [Errno 110] Connection timed out>
> > + tmp_cache_file.unlink()
> > + self.log.error("Unable to download %s: URL error %s",
> > + self.url, e)
> > + continue
>
> Hmm, I don't think we should retry on each and every URLError. For example
> if you have a typo in the server name, you get a "Name or service not known"
> URLError, and it does not make sense to retry in that case.
>
> Also, in case of the server being down, it takes a minute or two 'til the
> urllib gives up, so if you retry multiple times in that case, you can easily
> extend the test time by > 5 minutes (as you can see by the timestamps in the
> example in your cover letter), which is unfortunate, too (considering that
> there is also a timeout setting for the gitlab CI jobs).
>
> I think I'd maybe rather do something like this instead, without retrying
> the download, just marking certain errors as transient:
>
> except URLError as e:
> tmp_cache_file.unlink()
> msg = str(e.reason)
> self.log.error("Unable to download %s: URL error %s",
> self.url, msg)
> raise AssetError(self, msg,
> transient=("Network is unreachable" in msg))
>
> WDYT?
Ok, yes, we can do that instead.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
prev parent reply other threads:[~2025-08-30 16:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 8:31 [PATCH 0/3] tests/functional: improve handling flaky downloads Daniel P. Berrangé
2025-08-29 8:31 ` [PATCH 1/3] tests/functional: enable force refresh of cached assets Daniel P. Berrangé
2025-08-29 8:50 ` Thomas Huth
2025-08-29 9:04 ` Daniel P. Berrangé
2025-08-29 9:21 ` Thomas Huth
2025-08-29 8:31 ` [PATCH 2/3] tests/functional: fix formatting of exception args Daniel P. Berrangé
2025-08-29 8:52 ` Thomas Huth
2025-08-29 8:31 ` [PATCH 3/3] tests/functional: handle URLError when fetching assets Daniel P. Berrangé
2025-08-29 9:00 ` Thomas Huth
2025-08-29 9:08 ` Daniel P. Berrangé [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aLFt_KcyYpd3CyYt@redhat.com \
--to=berrange@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).