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 [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
