From: Fiona Ebner <f.ebner@proxmox.com>
To: Lukas Wagner <l.wagner@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 guest-common/manager 0/4] vzdump: add 'notification-mode' parameter
Date: Tue, 21 Nov 2023 13:34:41 +0100 [thread overview]
Message-ID: <bdd77d78-c420-470e-be62-c500575d9c3c@proxmox.com> (raw)
In-Reply-To: <786a840a-6c99-4a6b-946c-c2413afee735@proxmox.com>
Am 21.11.23 um 13:13 schrieb Lukas Wagner:
> On 11/21/23 11:55, Fiona Ebner wrote:
>> Am 21.11.23 um 11:22 schrieb Lukas Wagner:
>>> This should provide a fix/workaround for the users' reports of
>>> - double notifications (these happened in case mailto was set to
>>> the same address
>>> as root@pam)
>>
>> Can't we detect and avoid this more easily?
>
> There would be other ways to solve this, yes. I could also deduplicate
> email-addresses in the backend - which isn't is as trivial as it sounds,
> since the 'legacy' mails are sent via separate, temporary target of
> type 'sendmail' - so essentially I'd need to have 'cross-target' context
> or something alike.
>
Okay, I hoped you could get the information about whether the 'mailto'
address is already notified via existing targets more easily.
>>
>>> - notifications always being sent, even if 'mailnotification' is
>>> set to failure
>>
>> Can't we just treat 'failure' mode as always defaulting to legacy
>> sendmail? And properly deprecate the setting, showing a warning/info
>> that new notification system is not used if set to 'failure' for both
>> CLI and UI. And maybe not even allow setting it for new jobs/manual
>> backups?
>
> I think an explicit switch here is much more obvious and predictable to
> the user.
>
But also more complexity/mental load for both them and us. And having a
deprecation warning would also be obvious and predictable ;) Sure, we
(most likely) can get rid of the extra switch with PVE 9, was just
hoping for something simpler. But if that's not easily possible, then
let's go with the switch.
> Personally I think we should wait a bit before deprecating/disallowing
> 'mailto' for new backup jobs. This gives us time to polish the UX of
> creating matchers etc. without 'forcing' the user into the new system.
>
I didn't mean deprecating 'mailto' like that, just 'mailnotification'
(being set to 'failure').
next prev parent reply other threads:[~2023-11-21 12:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 10:22 Lukas Wagner
2023-11-21 10:22 ` [pve-devel] [PATCH v2 pve-guest-common 1/4] vzdump: config: add 'notification-mode' param for backup jobs Lukas Wagner
2023-11-21 12:32 ` [pve-devel] applied: " Thomas Lamprecht
2023-11-21 10:22 ` [pve-devel] [PATCH v2 pve-manager 2/4] vzdump: support 'notification-mode' parameter Lukas Wagner
2023-11-21 10:22 ` [pve-devel] [PATCH v2 pve-manager 3/4] ui: backup jobs: add 'notification-mode' selector for backup jobs Lukas Wagner
2023-11-21 10:22 ` [pve-devel] [PATCH v2 pve-manager 4/4] ui: backup: add 'notification-mode' param for one-shot " Lukas Wagner
2023-11-21 10:23 ` [pve-devel] [PATCH v2 guest-common/manager 0/4] vzdump: add 'notification-mode' parameter Lukas Wagner
2023-11-21 10:55 ` Fiona Ebner
2023-11-21 12:13 ` Lukas Wagner
2023-11-21 12:34 ` Fiona Ebner [this message]
2023-11-21 12:34 ` Thomas Lamprecht
2023-11-21 12:29 ` Philipp Hufnagl
2023-11-21 12:32 ` Thomas Lamprecht
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=bdd77d78-c420-470e-be62-c500575d9c3c@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=l.wagner@proxmox.com \
--cc=pve-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.