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 C97BC1FF191 for ; Tue, 7 Oct 2025 17:10:16 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 676691BDB6; Tue, 7 Oct 2025 17:10:19 +0200 (CEST) Message-ID: Date: Tue, 7 Oct 2025 17:09:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Thomas Lamprecht , Gabriel Goller References: <20250919094122.73373-1-g.goller@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.713 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [frrouting.org, proxmox.com] 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: Lukas Wagner Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 10/4/25 2:13 PM, Thomas Lamprecht wrote: > Am 19.09.25 um 11:41 schrieb Gabriel Goller: >> The third and probably most popular way (Vyos and Sonic both use jinja >> templates as well) to generate frr config is to use templates. So you basically >> have rust-structs that look similar to the frr config and implement derive or >> implemennt serialize. Then we can use template files, which contain the whole >> configuration with every option wrapped in a `if` block and lists/blocks >> wrapped in `for` loops. Finally, we can use the rust structs to insert them into >> the templates and get the full frr config. The major downside of this approach >> is that the frr template files get quite complicated and can be a major source >> of config generation errors. A positive thing though, is that we don't need to >> model the whole frr config with every option and every property, we can easily >> wrap a few options into a single (e.g.) bool, and then maybe split it out later >> when we add a ui option for each property. > > I mean, that should be possible in any representation, just needs separation of > types for the API and types to generate the (dumped) FRR config from.> One drawback is. that you loose type checks with templates, but that can be > made up by a regression test system (which is a necessity either way), so your > approach can be OK to me in general, but this needs to be Ack'ed also by Stefan. Imo some type-safety can still be upheld by e.g. using enums instead of simply Strings for fields in the templates that only accept certain keywords - same for fields that accept certain formats (IPs / CIDRs / ...). Nevertheless, a working and comprehensive integration / regression test system should accompany any approach we choose. One big upside of this approach, that hasn't really been mentioned yet, is imo the handling of FRR configuration overrides. What we currently do in pve-network is try and parse the FRR configuration into a Perl hash format with a implementation that supports only a subset of FRR (some examples for users running into limitations [1] [2]). Then we merge that parsed hash with a hash generated by the EvpnController and serialize everything out again. Getting this to work *properly* would basically require re-implementing and maintaining a full FRR configuration parser, which is no small feat [3]. Then add some custom merging logic on top, which brings its additional challenges. This problem will imo also worsen the more our generated FRR configuration grows. Providing templates as overrides makes that whole process much simpler for the users and for us and it is more in line with how we handle overrides e.g. in PMG or the notification system where that approach seems to work quite well afaict. Of course there's also drawbacks associated with that approach, like managing updates to the templates when overrides exist seems to crop up in PMG quite a few times. So I'd be interested to hear your opinions / experiences on that approach particularly wrt template overrides and if we have any learnings from that. Aside from that, templates seem to be the sanest option from my pov as well, particularly when compared to implementing a serde Serializer / Deserializer. That seemed quite tricky due to some quirks from the FRR configuration for. I don't remember the specific issues @Gabriel encountered but maybe @Gabriel can elaborate more on the issues he encountered when trying to go down that route. Part of that was why I suggested that Gabriel might want to look at using templates instead. 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. [1] https://forum.proxmox.com/threads/sdn-frr-conf-local-extcommunity-list.161977/ [2] https://forum.proxmox.com/threads/sdn-with-evpn-controller-routing-loop-when-using-multiple-exit-nodes.137362/#post-696569 [3] https://docs.frrouting.org/projects/dev-guide/en/latest/cli.html [4] https://docs.frrouting.org/projects/dev-guide/en/latest/northbound/northbound.html _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel