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 6A7F31FF17A for ; Fri, 4 Jul 2025 16:26:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D33B239C13; Fri, 4 Jul 2025 16:27:29 +0200 (CEST) Message-ID: Date: Fri, 4 Jul 2025 16:27:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Gabriel Goller , pve-devel@lists.proxmox.com References: <20250702145101.894299-1-g.goller@proxmox.com> <20250702145101.894299-59-g.goller@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: <20250702145101.894299-59-g.goller@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.528 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 POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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] [PATCH pve-manager v4 01/17] api: use new sdn config generation functions 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 7/2/25 16:50, Gabriel Goller wrote: > With the introduction of fabrics, frr configuration generation and > etc/network/interfaces generation has been reworked and renamed for > better clarity, since now not only zones / controllers are responsible > for generating the ifupdown / FRR configuration. Switch this endpoint > over to use the new functions. > > We also add a new skip_frr parameter that skips FRR config generation > if set. With the old FRR config generation logic, we never wrote an > empty FRR configuration if all controllers got deleted. This meant > that deleting all controllers still left the previous FRR > configuration on the nodes, never disabling BGP / IS-IS. The new logic > now writes an empty configuration if there is no controller / fabric > configured, fixing this behavior. This has a side effect for users > with an existing FRR configuration not managed by SDN, but utilizing > other SDN features (zones, vnets, ...). Their manual FRR configuration > would get overwritten when applying an SDN configuration. This is > particularly an issue with full-mesh Ceph setups, that were set up > according to our Wiki guide [1]. User with such a full-mesh setup > could get their FRR configuration overwritten when using unrelated SDN > features. Since this endpoint is called *after* committing the new SDN > configuration, but handles writing the FRR configuration, we need a > way to signal this endpoint to skip writing the FRR configuration from > the `PUT /cluster/sdn` endpoint, where we can check for this case. > > [1] https://pve.proxmox.com/mediawiki/index.php?title=Full_Mesh_Network_for_Ceph_Server&oldid=12146 > > Co-authored-by: Stefan Hanreich > Signed-off-by: Gabriel Goller > --- > PVE/API2/Network.pm | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm > index a8cd7649922b..dfefd2143ebe 100644 > --- a/PVE/API2/Network.pm > +++ b/PVE/API2/Network.pm > @@ -829,6 +829,11 @@ __PACKAGE__->register_method({ > additionalProperties => 0, > properties => { > node => get_standard_option('pve-node'), > + skip_frr => { > + type => 'boolean', > + description => 'Whether FRR config generation should get skipped or not.', > + optional => 1, > + }, > }, > }, > returns => { type => 'string' }, > @@ -843,6 +848,8 @@ __PACKAGE__->register_method({ > my $current_config_file = "/etc/network/interfaces"; > my $new_config_file = "/etc/network/interfaces.new"; > > + my $skip_frr = extract_param($param, 'skip_frr'); > + > assert_ifupdown2_installed(); > > my $worker = sub { > @@ -850,7 +857,7 @@ __PACKAGE__->register_method({ > rename($new_config_file, $current_config_file) if -e $new_config_file; > > if ($have_sdn) { > - PVE::Network::SDN::generate_zone_config(); > + PVE::Network::SDN::generate_etc_network_config(); > PVE::Network::SDN::generate_dhcp_config(); > } > Is it possible something got lost here in the rebase? See: https://lore.proxmox.com/pve-devel/20250522161731.537011-57-s.hanreich@proxmox.com/ _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel