From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Dominic Jäger" <d.jaeger@proxmox.com>,
"Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager 2/2] Close #1295: Make apt notifications configurable
Date: Thu, 8 Apr 2021 11:28:22 +0200 [thread overview]
Message-ID: <f332f511-3ca8-2ca8-6969-aeafba675aeb@proxmox.com> (raw)
In-Reply-To: <20210408092101.GA8824@mala>
On 08.04.21 11:21, Dominic Jäger wrote:
> On Wed, Apr 07, 2021 at 10:51:43AM +0200, Thomas Lamprecht wrote:
>> On 07.04.21 10:30, Dominic Jäger wrote:
>>> -# We assume that users with subscriptions want informations
>>> -# about new packages.
>>> -my $notify = ($info && $info->{status} eq 'Active') ? 1 : 0;
>>> +my $notify = $dccfg->{notify_updates} // 1;
>>
>> We may want to keep the default value the same, i.e.:
>>
>> my $notify = $dccfg->{notify_updates} // ($info && $info->{status} eq 'Active');
>
> Is there a reason why we assume that users without subscription do not want
> such notifications?
For a production-class setup a subscription is highly recommended, so we
can assume that without such one it is a test/evaluation setup where we may
not want to get the mails...
>
> As far as I see it, if we change it to
>> $dccfg->{notify_updates} // 1
> Then (until they change something)
> - users with active subscription should _continue_ to get notifications
> - enterprise repo configured but invalid subscription will continue to _not_
> get mails (because pveupdate exits with error 100)
this is not only for enterprise repo or? What if user disable the
enterprise repo in test system. Just keep the default...
>
> Then the only change is that users
> - without/invalid subscription and
> - with only no-subscription-repo configured
> will now suddenly get mails, but this is actually good?
>
> We could also append a line "You can deactivate these notifications in the
> Datacenter options" to the mail.
>
>>
>> (the following is actually meant for the pve-cluster patch):
>> I'd really prefer using a colon for new config property entries, and I
can imagine
>> that there will be more such switches in the future, so maybe start out with a format
>> sting (like migration is there) and have something like:
>>
>> 'notify: package-updates=1'
>>
>> what do you think?
> Done :) So the mentioned
>> $dccfg->{notify_updates} // 1
> is actually
>> my $notify = $dccfg->{notify}->{package_updates} // 1;
> already.
>
next prev parent reply other threads:[~2021-04-08 9:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 8:30 [pve-devel] [PATCH pve-cluster 1/2] Close #1295: Add notify_updates to datacenter schema Dominic Jäger
2021-04-07 8:30 ` [pve-devel] [PATCH manager 2/2] Close #1295: Make apt notifications configurable Dominic Jäger
2021-04-07 8:51 ` Thomas Lamprecht
2021-04-08 9:21 ` Dominic Jäger
2021-04-08 9:28 ` Thomas Lamprecht [this message]
2021-04-08 10:02 Dietmar Maurer
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=f332f511-3ca8-2ca8-6969-aeafba675aeb@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.jaeger@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox