all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	"DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
Subject: Re: [pve-devel] [PATCH frr 0/2] Bump FRR to 10.4.1
Date: Wed, 26 Nov 2025 17:00:26 +0100	[thread overview]
Message-ID: <70b51679-4f18-44e8-9578-e64c79509c40@proxmox.com> (raw)
In-Reply-To: <yhxsxfgzbesxasci72kmtb63ug43lqnth6udeh6kuvkn4uay7z@vnvxstqunfic>

Am 26.11.25 um 13:58 schrieb Gabriel Goller:
> On 25.11.2025 16:53, DERUMIER, Alexandre via pve-devel wrote:
>> Hi, 
>>
>> 10.4.2 has been released last week.
> 
> I don't think so? At least I can't see the tag on github...
> 
>> be carefull with frr updates, from my experience they are always to a
>> lot of bugs && regression when new major version is release,
>> and sometime it take weeks to triggers specific bugs in production.
>> (and even more to debug)
> 
> 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?
> 
> That said, I understand your concerns. We've also seen FRR being
> quite unstable lately with many regressions in recent releases. The
> maintainers have told me this should improve going forward.
> 
>> and frr still maintain 10.2 branch for example (10.2.5).
>>
>>
>> Personnaly, for my pve9 production, I'll pin my frr version to 10.2,
>> because I don't have time to retest new version each 6 months.
> 
> Pinning is always possible and something the user can do. Maybe we
> should create a official "guide" or article on how pin in case of
> critical network bugs.
> Obviously the newer features (e.g. fabrics) won't work.
> 
> I don't know how we handle other upstream dependencies that are critical
> yet optional? @Thomas?

We do not have many of those. But in general I agree with releasing
more often and in smaller increments being the better way almost all
of the time.

Version pinning is not something I'd heavily promote, but having an
article/how-to that describes how it could be done and what one needs
to watch out for makes definitively sense, as sometimes it's just the
fastest and simplest stop-gap.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  reply	other threads:[~2025-11-26 16:00 UTC|newest]

Thread overview: 7+ 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 [this message]
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=70b51679-4f18-44e8-9578-e64c79509c40@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=alexandre.derumier@groupe-cyllene.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal