public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>,
	"pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
	Gabriel Goller <g.goller@proxmox.com>
Subject: Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1
Date: Mon, 15 Dec 2025 08:57:35 +0100	[thread overview]
Message-ID: <bd94cf3f-65c4-41f2-8207-5edc25f50799@proxmox.com> (raw)
In-Reply-To: <9fcb92c222a931110010ae0be8d102cb4194ec99.camel@groupe-cyllene.com>

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


  parent reply	other threads:[~2025-12-15  7:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21 14:13 Gabriel Goller
2025-11-21 14:13 ` [pve-devel] [PATCH frr 1/2] bump frr to 10.4.1, remove obsolete patches Gabriel Goller
2025-11-21 14:13 ` [pve-devel] [PATCH frr 2/2] d/changelog: bump package version Gabriel Goller
2025-11-25 16:53 ` [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1 DERUMIER, Alexandre via pve-devel
2025-11-26 12:59   ` Gabriel Goller
2025-11-26 16:00     ` Thomas Lamprecht
2025-12-11  6:05     ` DERUMIER, Alexandre via pve-devel
     [not found]     ` <9fcb92c222a931110010ae0be8d102cb4194ec99.camel@groupe-cyllene.com>
2025-12-15  7:57       ` Thomas Lamprecht [this message]
2025-12-15  9:32         ` Gabriel Goller
2025-11-26 17:57 ` [pve-devel] applied: " Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd94cf3f-65c4-41f2-8207-5edc25f50799@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=alexandre.derumier@groupe-cyllene.com \
    --cc=g.goller@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal