From: Hanna Reitz <hreitz@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
Eduardo Habkost <ehabkost@redhat.com>,
qemu-block@nongnu.org, qemu-devel <qemu-devel@nongnu.org>,
Cleber Rosa <crosa@redhat.com>
Subject: Re: [PATCH 12/15] iotests: Disable AQMP logging under non-debug modes
Date: Mon, 4 Oct 2021 11:52:59 +0200 [thread overview]
Message-ID: <96337ed3-fcdf-ffa9-c938-3b4998f65420@redhat.com> (raw)
In-Reply-To: <CAFn=p-aaU8OK99R8u21SGb0kyOz=RtNy_aZoYnLwoOu6d4WE6A@mail.gmail.com>
On 18.09.21 02:58, John Snow wrote:
>
>
> On Fri, Sep 17, 2021 at 10:30 AM Hanna Reitz <hreitz@redhat.com
> <mailto:hreitz@redhat.com>> wrote:
>
> On 17.09.21 07:40, John Snow wrote:
> > Disable the aqmp logger, which likes to (at the moment) print out
> > intermediate warnings and errors that cause session termination;
> disable
> > them so they don't interfere with the job output.
> >
> > Leave any "CRITICAL" warnings enabled though, those are ones that we
> > should never see, no matter what.
>
> I mean, looks OK to me, but from what I understand (i.e. little),
> qmp_client doesn’t log CRITICAL messages, at least I can’t see
> any. Only
> ERRORs.
>
>
> There's *one* critical message in protocol.py, used for a circumstance
> that I *think* should be impossible. I do not think I currently use
> any WARNING level statements.
>
> I guess I’m missing some CRITICAL messages in external functions
> called
> from qmp_client.py, but shouldn’t we still keep ERRORs?
>
>
> ...Mayyyyyybe?
>
> The errors logged by AQMP are *almost always* raised as Exceptions
> somewhere else, eventually. Sometimes when we encounter them in one
> context, we need to save them and then re-raise them in a different
> execution context. There's one good exception to this: My pal, EOFError.
>
> If the reader context encounters EOF, it raises EOFError and this
> causes a disconnect to be scheduled asynchronously. *Any* Exception
> that causes a disconnect to be scheduled asynchronously is dutifully
> logged as an ERROR. At this point in the code, we don't really know if
> the user of the library considers this an "error" yet or not. I've
> waffled a lot on how exactly to treat this circumstance. ...Hm, I
> guess that's really the only case where I have an error that really
> ought to be suppressed. I suppose what I will do here is: if the
> exception happens to be an EOFError I will drop the severity of the
> log message down to INFO. I don't know why it takes being challenged
> on this stuff to start thinking clearly about it, but here we are.
> Thank you for your feedback :~)
Errr... You’re welcome!! *cough*
Hanna
next prev parent reply other threads:[~2021-10-04 10:01 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 5:40 [PATCH 00/15] Switch iotests to using Async QMP John Snow
2021-09-17 5:40 ` [PATCH 01/15] python/aqmp: add greeting property to QMPClient John Snow
2021-09-17 12:20 ` Hanna Reitz
2021-09-17 5:40 ` [PATCH 02/15] python/aqmp: add .empty() method to EventListener John Snow
2021-09-17 12:25 ` Hanna Reitz
2021-09-17 5:40 ` [PATCH 03/15] python/aqmp: Return cleared events from EventListener.clear() John Snow
2021-09-17 12:36 ` Hanna Reitz
2021-09-17 17:19 ` John Snow
2021-10-04 9:03 ` Hanna Reitz
2021-09-17 5:40 ` [PATCH 04/15] python/qmp: clear events on get_events() call John Snow
2021-09-17 12:51 ` Hanna Reitz
2021-09-17 17:31 ` John Snow
2021-09-17 5:40 ` [PATCH 05/15] python/qmp: add send_fd_scm directly to QEMUMonitorProtocol John Snow
2021-09-17 13:21 ` Hanna Reitz
2021-09-17 17:36 ` John Snow
2021-09-17 5:40 ` [PATCH 06/15] python, iotests: remove socket_scm_helper John Snow
2021-09-17 13:24 ` Hanna Reitz
2021-09-17 5:40 ` [PATCH 07/15] python/aqmp: add send_fd_scm John Snow
2021-09-17 13:34 ` Hanna Reitz
2021-09-17 18:05 ` John Snow
2021-09-17 5:40 ` [PATCH 08/15] python/aqmp: Create MessageModel and StandaloneModel classes John Snow
2021-09-17 13:39 ` Hanna Reitz
2021-09-17 19:21 ` John Snow
2021-09-17 5:40 ` [PATCH 09/15] python/machine: remove has_quit argument John Snow
2021-09-17 13:59 ` Hanna Reitz
2021-09-17 23:12 ` John Snow
2021-09-17 5:40 ` [PATCH 10/15] python/machine: Add support for AQMP backend John Snow
2021-09-17 14:16 ` Hanna Reitz
2021-09-17 23:48 ` John Snow
2021-10-04 9:43 ` Hanna Reitz
2021-09-17 5:40 ` [PATCH 11/15] python/aqmp: Create sync QMP wrapper for iotests John Snow
2021-09-17 14:23 ` Hanna Reitz
2021-09-18 0:01 ` John Snow
2021-09-17 5:40 ` [PATCH 12/15] iotests: Disable AQMP logging under non-debug modes John Snow
2021-09-17 14:30 ` Hanna Reitz
2021-09-18 0:58 ` John Snow
2021-09-18 2:14 ` John Snow
2021-10-04 10:12 ` Hanna Reitz
2021-10-04 18:32 ` John Snow
2021-10-04 21:26 ` John Snow
2021-10-05 15:12 ` Hanna Reitz
2021-10-04 9:52 ` Hanna Reitz [this message]
2021-09-17 5:40 ` [PATCH 13/15] iotests: Accommodate async QMP Exception classes John Snow
2021-09-17 14:35 ` Hanna Reitz
2021-09-18 1:12 ` John Snow
2021-09-17 5:40 ` [PATCH 14/15] python/aqmp: Remove scary message John Snow
2021-09-17 14:38 ` Hanna Reitz
2021-09-17 15:15 ` John Snow
2021-09-17 5:40 ` [PATCH 15/15] python, iotests: replace qmp with aqmp John Snow
2021-09-17 14:40 ` Hanna Reitz
2021-09-17 14:55 ` John Snow
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=96337ed3-fcdf-ffa9-c938-3b4998f65420@redhat.com \
--to=hreitz@redhat.com \
--cc=crosa@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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).