From: Gabriel Goller <g.goller@proxmox.com>
To: Christian Ebner <c.ebner@proxmox.com>
Cc: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] log: retrieve `ReaderEnvironment` debug flag from tracing
Date: Tue, 16 Jul 2024 11:07:47 +0200 [thread overview]
Message-ID: <20240716090747.7fpck6k5bktz3hgv@luna.proxmox.com> (raw)
In-Reply-To: <f166e0f4-ae95-415e-8bf7-c150473f6d35@proxmox.com>
On 16.07.2024 10:21, Christian Ebner wrote:
>one comment inline
>
>On 7/15/24 17:13, Gabriel Goller wrote:
>>@@ -687,12 +688,16 @@ impl BackupEnvironment {
>> }
>> pub fn log<S: AsRef<str>>(&self, msg: S) {
>>- self.worker.log_message(msg);
>>+ info!("{}", msg.as_ref());
>> }
>> pub fn debug<S: AsRef<str>>(&self, msg: S) {
>> if self.debug {
>>- self.worker.log_message(msg);
>>+ // This is kinda weird, we would like to use debug! here and automatically filter it,
>>+ // but self.debug is set from the client-side and the logs are printed on client and
>>+ // server side. This means that if the client sets the log level to debug, both server
>>+ // and client need to have 'debug' logs printed.
>>+ info!("{}", msg.as_ref());
>
>This is indeed a bit odd: The fact that the client can set the `debug`
>flag when upgrading to the backup protocol, but cannot and should not
>control the filter level makes this a bit strange.
Yeah, this is indeed kind of weird.
But I don't even think it's that stupid, because the output will be
printed on both server and client, so the client setting the loglevel is
fine I guess.
>So I would suggest to rename this method to something like
>`client_debug` (or something better fitting?)
Hmm, I don't know, the function doesn't only print to the client, it
also prints to the tasklog and thus on the server.
>and instead of calling the `info` macro directly, call `self.log`
>instead if `self.debug` is set. By this, it should at least be a bit
>more clear what is going on and one cannot accidentally loose these
>debug messages as the same codepath is then used for generating the
>event.
Yeah, that's a good idea...
I also though about adding the same stuff to the ReaderEnvironment as it
basically does the same thing.
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
prev parent reply other threads:[~2024-07-16 9:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 15:13 Gabriel Goller
2024-07-16 8:21 ` Christian Ebner
2024-07-16 8:38 ` Christian Ebner
2024-07-16 9:07 ` Gabriel Goller [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=20240716090747.7fpck6k5bktz3hgv@luna.proxmox.com \
--to=g.goller@proxmox.com \
--cc=c.ebner@proxmox.com \
--cc=pbs-devel@lists.proxmox.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.