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 6CFCE1FF178 for ; Mon, 15 Dec 2025 08:56:55 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B5E0E2580; Mon, 15 Dec 2025 08:57:38 +0100 (CET) Message-ID: Date: Mon, 15 Dec 2025 08:57:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , Gabriel Goller References: <20251121141446.349501-1-g.goller@proxmox.com> <9fcb92c222a931110010ae0be8d102cb4194ec99.camel@groupe-cyllene.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <9fcb92c222a931110010ae0be8d102cb4194ec99.camel@groupe-cyllene.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1765785448420 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.022 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 Subject: Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1 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" Hi, Am 11.12.25 um 07:05 schrieb DERUMIER, Alexandre: >>> Yeah, that's exactly why I want to release every minor FRR version >>> (while staying one release behind). This approach should minimize >>> the impact when a major version is released. The big issue with PVE >>> 8.5 was jumping from FRR 8 to 10 -- that's two major versions at >>> once, which caused many problems. I believe it's better to do >>> frequent small updates where issues are discovered quickly, rather >>> than large yearly updates where many problems surface at once. >>> >>> What do you think about this? > > Well, It's like ceph, you don't want uncontrolled major upgrade. (Minor > are ok, because they are only backporting small patches). > > so , doing it during major PVE upgrade is ok. or adding a version > handling like ceph. If we would add versioned FRR, I'd rather use the approach from the kernel over the one from ceph. I.e., add the version to the frr package names and provide a meta package that depends on the default one over having a dedicated repo like we do for ceph. That said, I'd be prefer if we could avoid doing this, as it's not a panacea on it's own. It adds confusion and complexity for not only us (that can be managed) but also our users (like having more easily multiple different FRR versions in a cluster). It can be an option to re-evaluate though. > The only problem is that they don't have an LTS for security upgrade > > This is a criticial part of infrastructure, even more criticial than > ceph Definitively, but that with the potential complexity is also a reason of seldom big updates not being ideal either. >>> That said, I understand your concerns. We've also seen FRR being >>> quite unstable lately with many regressions in recent releases. >>> > > FRR updates always had regression, when I had implement evpn I had > regression with 7.5,7.6,7.8,8.0,8.1 as far I remember. > > so, you really don't need to big gap to have problem, it's occur all > time (I don't known, they don't seem to have automatic test on readl > infra) Maybe something Gabriel could look into, as I'd prefer upstream testing more over us testing more, while both are required, the former helps every FRR user and should avoid some redundant effort. > here we go again.... :/ > > https://forum.proxmox.com/threads/frr-update-to-10-4-1-1-broke-external-routing.177736/ This specific issue seems to have been our fault though :/ >>> The maintainers have told me this should improve going forward. > > don't trust them ;) Hmm, I really get that you have been burned a bit too often by them, but IMO the only good possibility to improve on their releases for our users in the mid/longterm is to more frequently update in smaller steps, and then give feedback or (cherry-pick) fixes back. And with Gabriel we now have a depth that is a bit more involved with upstream, so I have more confidence in that working out, albeit I certainly do not expect wonders (quickly). In any case, we'll certainly move FRR updates, especially those for new releases along more slowly. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel