[pve-devel] [RFC network/ve-rs 0/8] Template-based FRR config generation

[Lukas Wagner]

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