From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 31F061FF2AF for ; Mon, 22 Jul 2024 09:50:17 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2BD391D489; Mon, 22 Jul 2024 09:50:48 +0200 (CEST) Message-ID: <1a4b5e7e-cb9f-4b1b-a7ac-c24a2a2768e2@proxmox.com> Date: Mon, 22 Jul 2024 09:50:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Max Carrara , pbs-devel@lists.proxmox.com References: <20240712112755.123630-1-l.wagner@proxmox.com> Content-Language: de-AT, en-US From: Lukas Wagner In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.007 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [RFC many v2 00/12] notifications: add support for webhook endpoints X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 2024-07-17 17:34, Max Carrara wrote: > On Fri Jul 12, 2024 at 1:27 PM CEST, Lukas Wagner wrote: >> Sending as an RFC because I don't want this merged yet; that being >> said, the feature should be mostly finished at this point, I'd >> appreciate any reviews and feedback. >> >> This series adds support for webhook notification targets to PVE >> and PBS. >> >> A webhook is a HTTP API route provided by a third-party service that >> can be used to inform the third-party about an event. In our case, >> we can easily interact with various third-party notification/messaging >> systems and send PVE/PBS notifications via this service. >> The changes were tested against ntfy.sh, Discord and Slack. >> >> The configuration of webhook targets allows one to configure: >> - The URL >> - The HTTP method (GET/POST/PUT) >> - HTTP Headers >> - Body >> >> One can use handlebar templating to inject notification text and metadata >> in the url, headers and body. >> >> One challenge is the handling of sensitve tokens and other secrets. >> Since the endpoint is completely generic, we cannot know in advance >> whether the body/header/url contains sensitive values. >> Thus we add 'secrets' which are stored in the protected config only >> accessible by root (e.g. /etc/pve/priv/notifications.cfg). These >> secrets are accessible in URLs/headers/body via templating: >> >> Url: https://example.com/{{ secrets.token }} >> >> Secrets can only be set and updated, but never retrieved via the API. >> In the UI, secrets are handled like other secret tokens/passwords. >> >> Bumps for PVE: >> - libpve-rs-perl needs proxmox-notify bumped >> - pve-manager needs bumped proxmox-widget-toolkit and libpve-rs-perl bumped >> - proxmox-mail-forward needs proxmox-notify bumped >> >> Bumps for PBS: >> - proxmox-backup needs proxmox-notify bumped >> - proxmox-mail-forward needs proxmox-notify bumped > > Since this is an RFC, I mainly just did some proofreading; I haven't > really spotted anything out of the ordinary, apart from a few *very > small* things I commented on inline. > > I like the overall idea of adding webhooks, so this looks pretty solid > to me. At first I thought that this might be a bit of a niche use case, > but I feel like it might actually be quite interesting for orgs that are > e.g. on Slack: You could e.g. just "route" all notifications via a > webhook to Slack, and Slack then sends a push notification to one's > phone. The same can obviously done with other applications / services as > well. So, pretty cool stuff :) > > Not sure if this has been discussed somewhere already (off list etc.), > but could you elaborate on why you don't want this merged yet? The > patches look pretty solid to me, IMHO. Then again, I haven't really > tested them yet due to all the required package bumps, so take this with > a grain of salt. > > If you want to have this RFC tested, I can of course give it a shot - do > let me know if that's the case :) > I posted this as an RFC because while I consider this as mostly finished, it did not yet go through my own rigorous self-review/testing. I had to switch to some other task and wanted to get this version out to get some general feedback. There are no changes planned unless I or somebody else discovers any issues, so I'd very much welcome any testing :) -- - Lukas _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel