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 F359B1FF165 for ; Thu, 9 Oct 2025 11:57:04 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 623E71B26F; Thu, 9 Oct 2025 11:57:09 +0200 (CEST) Mime-Version: 1.0 Date: Thu, 09 Oct 2025 11:57:05 +0200 Message-Id: To: "Proxmox VE development discussion" , "Thomas Lamprecht" , "Gabriel Goller" From: "Lukas Wagner" X-Mailer: aerc 0.20.1-0-g2ecb8770224a References: <20250919094122.73373-1-g.goller@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1760003793787 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.027 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 KAM_SHORT 0.001 Use of a URL Shortener for very short URL 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 network/ve-rs 0/8] Template-based FRR config generation 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 Cc: pve-devel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On Tue Oct 7, 2025 at 5:09 PM CEST, Stefan Hanreich wrote: > Alternatively, there's the Northbound API [4] which uses YANG for its > configuration language, but it doesn't seem ready yet and lacks support > for e.g. bgpd. > >> The third option of using two template engines is naturally also one, but actively >> and knowingly planing a schism is not something I'd promote much either tbh. > > Fully agree that using one templating engine across all our codebase > instead of using FOTM templating language seems far better. I don't > think minijinja could bring any upside that would outweigh that. > Some thoughts from my side. >From what I've seen so far, minijinja seems quite promising. It wasn't really on my radar when I implemented the initial version of the notification stack -- we already used handlebars in PBS and minijinja was not released yet (or in a rather early version). While it would be a bit of work, I would generally be okay with the idea of switching to minijinja in the long term. At this moment, handlebars is used for the following parts of the notification stack: - Notification title/body - Webhook headers and body For some transition period we would need to support both engines. For the notification body/title we could decide which engine to use based on the template filename extension (either .hbs or .j2). For the webhook body, where the template string is part of the configuration, we would probably need to add a configuration flag which allows the user to choose between Handlebars syntax and jinja syntax. Some of the benefits I see with minijinja: - minijinja provides a large number of built-in helpers [1], many of which could be very useful when writing notification templates / webhook body templates. For the current handlebars impl I've implemented a tiny subset of these by hand (escape, json, etc.). Indeed, just today I've helped a user in the forum [2] for which the 'map' function could be potentially useful, in order to set up a custom severity mapping for their webhook body payload. In bugzilla, somebody has also requested a 'truncate' helper to limit the webhook body length; this one would also come for free with minijinja. - I don't have concrete evidence to support this, but I'd assume the average sysadmin is likely to be more familiar with the j2 syntax than the Handlebars one, mostly due to the popularity of Ansible. - The minijinja maintainer is the same person as the original author of jinja [3] - so the chances of syntax incompatibilities between minijinja and the reference implementation should hopefully be small. On the other hand, with handlebars-rs, we recently ran into breaking changes in template rendering when switching to a new major version, which was due to the handlebars-rs fixing inconsistencies with the reference implementation (JS) [4]. - minijinja explicitly supports being compiled to WebAssembly. Could be useful in the future for having a 'notification template editor' with a rendered preview and/or live syntax checking for the template. (That being said, seems like handlebars-rs also supports wasm-compilation now, so this is not really a deciding factor anymore) Some of the downsides: - As mentioned above, additional work to support a second template engine for a while - Potential for user error/confusion in the transitory period (using the wrong syntax in the wrong template type) - Potential disruption for the user when we eventually phase out handlebars. The number of users using custom notification templates is probably rather small, but it seems like quite a lot of our homelab users use the webhook integration. [1] https://docs.rs/minijinja/latest/minijinja/filters/index.html#functions [2] https://forum.proxmox.com/threads/webhook-notifications-empty-fields-and-pagerduty.173503/post-807200 [3] https://jinja.palletsprojects.com/en/stable/ [4] https://git.proxmox.com/?p=proxmox-backup.git;a=commit;h=085b6c0e5ea3ed2634657221dae5fa121a636541 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel