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 C928A1FF140 for ; Fri, 27 Mar 2026 02:12:03 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 574011F552; Fri, 27 Mar 2026 02:12:24 +0100 (CET) Message-ID: <7564a8cf-58d3-41ff-926d-0485e9e6e02a@proxmox.com> Date: Fri, 27 Mar 2026 02:11:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH manager/network/proxmox{-ve-rs,-perl-rs} v7 00/21] Generate frr config using jinja templates and rust types To: Gabriel Goller , pve-devel@lists.proxmox.com References: <20260323134934.243110-1-g.goller@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20260323134934.243110-1-g.goller@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1774573860667 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.009 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 Message-ID-Hash: FHX6TN665MY3EP7NI3MQ7CRODC2WRPBD X-Message-ID-Hash: FHX6TN665MY3EP7NI3MQ7CRODC2WRPBD X-MailFrom: t.lamprecht@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 X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 23.03.26 um 14:49 schrieb Gabriel Goller: > Previously we generated the frr config using one big perl hash, where every > controller-plugin and zone-plugin would push their stuff. This is not pretty > and also tricky to unite with our new rust-based fabrics. Furthermore the only > way to edit or override the frr config is currently the frr.conf.local file, > which is merged with the perl-hash in a very janky manner, which has sprouted > numerous forum threads. The main problem with the frr.conf.local is the limited > control which the user has as to where the override or additional config gets > placed. There are also a few config overrides or additions to frr.conf.local > that are currently impossible or generate invalid frr config. > > To improve this we now ship templates, which we use to generate the frr config. > This is the way it is done in e.g. sonic and vyos. These jinja2 templates are > then populated using rust-structs. We changed the perl code to generate > bgp/evpn and isis config that can be deserialized by the rust types and then > rendered into a frr configuration using the templates. > > # Versioning > > The templates are in the proxmox-frr-templates debian package which, when > installed, copies the template into `/usr/share/proxmox-frr/templates`, where > they are read from using `include_str!`. This means the proxmox-frr-templates > package is only used for development and to version the templates. The user > only gets them in the binary of proxmox-frr (which, by extension, is in the > perl-rs shared library). > > # frr.conf.local > > The frr.conf.local merging code has been adjusted so that the frr.conf.local > still works as before. > > This series requires: > https://lore.proxmox.com/pve-devel/20260323092140.42275-1-g.goller@proxmox.com/ > > Changelog: > > v7 (thanks @Wolfgang, @Stefan): > * ve-rs: remove `phf` dependency, use proxmox-sorted-macro and const array > with binary_search lookup > * ve-rs: add proxmox-frr unit-tests using vtysh dry-run to test them directly > against the frr config parser (only if the vtysh binary exists) > * ve-rs: use new from_str implementation of api_string_type! macro (requires: > https://lore.proxmox.com/pve-devel/20260323092140.42275-1-g.goller@proxmox.com/) Reads like a mature and well structured series, nice work! Some comments to specific patches, but most of it relatively benign (or at least easy to fix). With those addressed, if applicable, this would be IMO ready to be applied. Please pick up Wolfgang R-b for a next submission, at least if you do not make bigger structural code changes. OTOH, I'd be open to squash in a few fixes and take this in after you checked the replies, just tell me what you favor; I'm also more then content with a v8 submission.