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 47EF61FF185 for ; Mon, 4 Aug 2025 16:09:45 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0804133215; Mon, 4 Aug 2025 16:11:16 +0200 (CEST) Message-ID: <0900512d-f61f-4c5d-a5f9-84dc18eb2243@proxmox.com> Date: Mon, 4 Aug 2025 16:11:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion References: <20250804134706.408039-1-s.hanreich@proxmox.com> <20250804134706.408039-2-s.hanreich@proxmox.com> <922690fd-414b-4a12-b994-82de7d59c151@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: <922690fd-414b-4a12-b994-82de7d59c151@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.707 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 Subject: Re: [pve-devel] [PATCH pve-manager 1/1] api: network: default to not regenerating the frr configuration 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 8/4/25 4:07 PM, Thomas Lamprecht wrote: > Am 04.08.25 um 15:46 schrieb Stefan Hanreich: >> Default to not regenerating the FRR configuration, unless explicitly >> requested. Otherwise applying the host network configuration would >> reload and enable the FRR service. Invert the boolean from skip to >> regenerate, since the logic is less convoluted this way. > > > and casually break API and reloading SDN during the upgrade, while > triggering such updates might be not the best idea to do in the first > place it would be at least good to call it out here. > > FWIW, if we'd walk the full mile here we probably would keep the old > param as fallback and check the node version from the pmxcs in memory > kv store in pve-network to determine what param to send to the other > nodes. > > That said, I can live with skip doing that, it is a major release > after all. Just ensure you have upgrades on your mind or, if you had, > add a note for that next time. The parameter has been introduced in PVE 9 with the SDN fabrics, so it should be fine to change this. Sorry, I should've at least mentioned it. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel