From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <t.lamprecht@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id C8834901EF
for <pbs-devel@lists.proxmox.com>; Wed, 5 Oct 2022 17:28:45 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 9F8B03976
for <pbs-devel@lists.proxmox.com>; Wed, 5 Oct 2022 17:28:15 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pbs-devel@lists.proxmox.com>; Wed, 5 Oct 2022 17:28:14 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 1782E445DA
for <pbs-devel@lists.proxmox.com>; Wed, 5 Oct 2022 17:28:14 +0200 (CEST)
Message-ID: <897a1cc4-1ca8-2173-9752-d378b3f4e8ec@proxmox.com>
Date: Wed, 5 Oct 2022 17:28:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101
Thunderbird/106.0
Content-Language: en-GB
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com>
References: <20220712102259.2325389-1-d.csapak@proxmox.com>
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <20220712102259.2325389-1-d.csapak@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 1.195 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
NICE_REPLY_A -2.449 Looks like a legit reply (A)
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [jobs.rs, datastore.rs]
Subject: Re: [pbs-devel] [PATCH proxmox-backup] implement prune notifications
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2022 15:28:45 -0000
Conflicts, but is auto-, but there's a compile error (see inline).
Am 12/07/2022 um 12:22 schrieb Dominik Csapak:
> we converted the prune settings of datastores to prune-jobs, but did
> not actually implement the notifications for them, even though
> we had the notification options in the gui (they did not work).
>
> implement the basic ok/error notification for prune jobs
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> if we want we could collect some basic info about the pruning,
> like how many snapshots we removed/kept
can always add that in the future
>
> adding the whole list of which snapshots were kept/deleted does
> not really make sense to me though, thats the purpose of the task log
>> pbs-api-types/src/jobs.rs | 6 +++
> src/api2/config/datastore.rs | 1 +
> src/server/email_notifications.rs | 74 +++++++++++++++++++++++++++++++
> src/server/prune_job.rs | 9 ++++
> www/window/NotifyOptions.js | 2 +-
> 5 files changed, 91 insertions(+), 1 deletion(-)
>
> +pub fn send_prune_status(
> + email: &str,
fwiw, we could use Option<&str> here and re-use/extend the existing match+early return
to avoid caller headache. We even could drop it completely and call the
lookup_datastore_notify_settings internally, if we ever got other call sites
we can still re-factor it out again or have two methods, an auto variant and a
manual one.
> diff --git a/src/server/prune_job.rs b/src/server/prune_job.rs
> index a62177e4..e9631183 100644
> --- a/src/server/prune_job.rs
> +++ b/src/server/prune_job.rs
> @@ -169,6 +169,8 @@ pub fn do_prune_job(
> None => format!("{store}"),
> };
>
> + let (email, notify) = crate::server::lookup_datastore_notify_settings(&store);
> +
> let upid_str = WorkerTask::new_thread(
> &worker_type,
> Some(worker_id),
> @@ -191,6 +193,13 @@ pub fn do_prune_job(
> eprintln!("could not finish job state for {}: {}", job.jobtype(), err);
> }
>
> + if let Some(email) = email {
> + if let Err(err) =
> + crate::server::send_prune_status(&email, notify, &store, job.jobname(), &result)
compilation errors because your referencing store, which got moved into worker_id above,
simplest thing may be to clone there, I mean we could use &worker.upid().worker_id (it's
pub) but that would be rather a bit ugly IMO.
> + {
> + eprintln!("send prune notification failed: {}", err);
You got that probably from context, but we normally use the log crates fn's over
eprintln for new code IIRC.
> + }
> + }
> result
> },
> )?;