From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id B0B871FF13B for ; Wed, 11 Feb 2026 13:46:57 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CCB631BC4E; Wed, 11 Feb 2026 13:47:41 +0100 (CET) Date: Wed, 11 Feb 2026 13:47:36 +0100 From: Arthur Bied-Charreton To: Lukas Wagner Subject: Re: [PATCH pve-manager 1/5] notifications: Add OAuth2 parameters to schema and add/update endpoints Message-ID: <5bv6xdgireomyp746swbty4r3r6jontuv356qlhluepj7zrk26@ua4ve4segvxo> References: <20260204161354.458814-1-a.bied-charreton@proxmox.com> <20260204161354.458814-10-a.bied-charreton@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770813971846 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.861 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: SFZKQZ7GDK2Z5GORKQ4QUQ52VXRWDG4D X-Message-ID-Hash: SFZKQZ7GDK2Z5GORKQ4QUQ52VXRWDG4D X-MailFrom: a.bied-charreton@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Feb 11, 2026 at 09:55:23AM +0100, Lukas Wagner wrote: > On Wed Feb 4, 2026 at 5:13 PM CET, Arthur Bied-Charreton wrote: > > Add auth-method, as well as optional > > oauth2-{client-id,client-secret,tenant-id,refresh-token} parameters to > > prepare for OAuth2 support. > > > > The auth-method parameter was previously implicit and inferred by > > proxmox-notify based on the presence of a password. It is now made > > explicit, however still kept optional and explicitly inferred in the > > {update,create}_endpoint handlers to avoid breaking the API. > > > > Signed-off-by: Arthur Bied-Charreton > > --- > > PVE/API2/Cluster/Notifications.pm | 55 +++++++++++++++++++++++++++++++ > > 1 file changed, 55 insertions(+) > > [...] > > eval { > > PVE::Notify::lock_config(sub { > > my $config = PVE::Notify::read_config(); > > @@ -1208,6 +1258,11 @@ __PACKAGE__->register_method({ > > $mode, > > $username, > > $password, > > + $auth_method, > > + $oauth2_client_id, > > + $oauth2_client_secret, > > + $oauth2_tenant_id, > > + $oauth2_refresh_token, > > $mailto, > > $mailto_user, > > $from_address, > > As already explained off-list, I think it's time to switch from a flat > list of parameters to passing hashes for the parameters for the > `add_smtp_target` and `update_smtp_target` methods. This means, the > bindings in proxmox-perl-rs would then directly take > SmtpConfig/SmtpPrivateConfig and > SmtpConfigUpdater/SmtpPrivateConfigUpdater. Then the call could look > something like (not tested) > > $config->add_smtp_endpoint( > $name, > { > server => $server, > port => $port, > ... > }, > { > password => $password, > ... > } > ); > > This makes it much harder to introduce bugs due to parameter ordering. > Long-term we should do the same for the other endpoints, but no need to > do it in this series, I think. > That makes a lot of sense, will update it > For changes like these and in general it's pretty important to mention > any breaking changes in the cover letter and maybe patch description, > since the changes done in this series affect multiple packages that > *could* be updated independently by our users. For instance, in the > cover-letter you could write something like: > > The patch series requires the following version requirement bumps: > > pve-manager requires bumped proxmox-perl-rs > proxmox-perl-rs requires bumped proxmox-notify* > > > *.) although for this one it's not that critical, since its only a > build-dependency, so there is no chance of customer systems breaking due > to partial system updates > > This way the maintainer knows that the version requirements in > debian/control must be adapted at some point after applying the patches. I was wondering how this would work, thanks for the explanation!