From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Thomas Huth" <thuth@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>, qemu-devel@nongnu.org
Subject: Re: [RFC PATCH] tests/functional: Don't fail any precaching errors
Date: Wed, 12 Mar 2025 16:55:56 +1000 [thread overview]
Message-ID: <D8E3AO9HFZHM.29ZMK97VP5Z3Q@gmail.com> (raw)
In-Reply-To: <45d36146-3d2c-421e-b58c-0b1ef50ee81a@redhat.com>
On Wed Mar 12, 2025 at 4:36 PM AEST, Thomas Huth wrote:
> On 12/03/2025 00.41, Nicholas Piggin wrote:
> ...
>> I think *no* precaching errors including 404 should cause
>> failure because you would still want other tests to proceed
>> (in some cases).
>>
>> But the failure should be caught when the test case tries to
>> fetch the asset, so you can still easily identify the download
>> failure.
>
> Sorry, I did not get that... if we ignore the 404 during the precaching
> step, how should the failure be caught when the test runs? The downloads are
> disabled that case, so the test cannot know whether the asset is not
> available due to a 404 or any other reason...?
Right, it would need something to get that error to the test case.
I had not thought too much about it if there is disagreement about
it being a good solution then no point.
But some possibilities:
- downloads could be enabled even for pre-cache case
- the pre-cache step could build an in-memory dictionary of the
assets
- some additional file name or attribute could be added to the
pre-cache to convey status
I didn't follow the asset caching rework too closely so I could be
well off the mark, but I would look into 1 first since it might be
simplest. If that does not work maybe an in-memory metadata of
assets might not be too hard and could help with flexibility in
future.
Thanks,
Nick
prev parent reply other threads:[~2025-03-12 6:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-11 13:13 [RFC PATCH] tests/functional: Don't fail any precaching errors Nicholas Piggin
2025-03-11 13:37 ` Daniel P. Berrangé
2025-03-11 13:55 ` Thomas Huth
2025-03-11 14:11 ` Daniel P. Berrangé
2025-03-12 5:54 ` Nicholas Piggin
2025-03-11 23:41 ` Nicholas Piggin
2025-03-12 6:36 ` Thomas Huth
2025-03-12 6:55 ` Nicholas Piggin [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=D8E3AO9HFZHM.29ZMK97VP5Z3Q@gmail.com \
--to=npiggin@gmail.com \
--cc=berrange@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.