From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Fabiano Rosas <farosas@suse.de>,
qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [RFC PATCH 0/2] qtest: Log verbosity changes
Date: Fri, 6 Sep 2024 09:14:11 +0100 [thread overview]
Message-ID: <Ztq5068xW640qeuD@redhat.com> (raw)
In-Reply-To: <95d9509b-d9a5-467a-860a-91bcd4baae1f@redhat.com>
On Fri, Sep 06, 2024 at 08:16:31AM +0200, Thomas Huth wrote:
> On 05/09/2024 23.03, Fabiano Rosas wrote:
> > Hi,
> >
> > This series silences QEMU stderr unless the QTEST_LOG variable is set
> > and silences -qtest-log unless both QTEST_LOG and gtest's --verbose
> > flag is passed.
> >
> > This was motivated by Peter Maydell's ask to suppress deprecation
> > warn_report messages from the migration-tests and by my own
> > frustration over noisy output from qtest.
>
> Not sure whether we want to ignore stderr by default... we might also miss
> important warnings or error messages that way...?
I would prefer if our tests were quiet by default, and just printed
clear pass/fail notices without extraneous fluff. Having an opt-in
to see full messages from stderr feels good enough for debugging cases
where you need more info from a particular test.
Probably we should set verbose mode in CI though, since it is tedious
to re-run CI on failure to gather more info
> If you just want to suppress one certain warning, I think it's maybe best to
> fence it with "if (!qtest_enabled()) { ... }" on the QEMU side - at least
> that's what we did in similar cases a couple of times, IIRC.
We're got a surprisingly large mumber of if(qtest_enabled()) conditions
in the code. I can't help feeling this is a bad idea in the long term,
as its making us take different codepaths when testing from production.
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 :|
next prev parent reply other threads:[~2024-09-06 8:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 21:03 [RFC PATCH 0/2] qtest: Log verbosity changes Fabiano Rosas
2024-09-05 21:03 ` [RFC PATCH 1/2] tests/qtest: Mute QEMU stderr Fabiano Rosas
2024-09-05 21:03 ` [RFC PATCH 2/2] tests/qtest: Mute -qtest-log Fabiano Rosas
2024-09-06 6:16 ` [RFC PATCH 0/2] qtest: Log verbosity changes Thomas Huth
2024-09-06 8:14 ` Daniel P. Berrangé [this message]
2024-09-06 9:52 ` Peter Maydell
2024-09-06 14:42 ` Fabiano Rosas
2024-09-13 10:02 ` Markus Armbruster
2024-09-13 10:08 ` Peter Maydell
2024-09-13 11:29 ` Markus Armbruster
2024-09-13 11:46 ` Peter Maydell
2024-09-13 12:14 ` Thomas Huth
2024-09-13 11:56 ` Daniel P. Berrangé
2024-09-14 9:35 ` Markus Armbruster
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=Ztq5068xW640qeuD@redhat.com \
--to=berrange@redhat.com \
--cc=farosas@suse.de \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--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 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).