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 9B8AE1FF136 for ; Mon, 20 Apr 2026 15:34:03 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DC13A23E8; Mon, 20 Apr 2026 15:34:02 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 20 Apr 2026 15:33:27 +0200 Message-Id: To: "Friedrich Weber" , =?utf-8?q?Michael_K=C3=B6ppl?= , Subject: Re: [PATCH cluster 2/5] pvecm: warn users of high token timeouts when using nodes command From: =?utf-8?q?Michael_K=C3=B6ppl?= X-Mailer: aerc 0.21.0 References: <20260330144321.321072-1-m.koeppl@proxmox.com> <20260330144321.321072-3-m.koeppl@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776691923622 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.102 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 Message-ID-Hash: 3TWETPBFTBUU6WH4KQXC2QGVV2ZB4XJ3 X-Message-ID-Hash: 3TWETPBFTBUU6WH4KQXC2QGVV2ZB4XJ3 X-MailFrom: m.koeppl@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri Apr 17, 2026 at 10:33 AM CEST, Friedrich Weber wrote: > On 30/03/2026 16:47, Michael K=C3=B6ppl wrote: >> If the calculated token timeout is above certain thresholds, display a >> warning for users when running `pvecm nodes`. Also points users to the >> documentation regarding potential adaptations to their cluster >> configuration to alleviate the problem. >>=20 >> Signed-off-by: Michael K=C3=B6ppl >> --- >> src/PVE/CLI/pvecm.pm | 9 +++++++++ >> 1 file changed, 9 insertions(+) >>=20 >> diff --git a/src/PVE/CLI/pvecm.pm b/src/PVE/CLI/pvecm.pm >> index 7d393a8..561c5f6 100755 >> --- a/src/PVE/CLI/pvecm.pm >> +++ b/src/PVE/CLI/pvecm.pm >> @@ -584,6 +584,15 @@ __PACKAGE__->register_method({ >> =20 >> PVE::Corosync::check_conf_exists(); >> =20 >> + my $conf =3D PVE::Cluster::cfs_read_file("corosync.conf"); >> + my $nodelist =3D PVE::Corosync::nodelist($conf); >> + my $totem_cfg =3D PVE::Corosync::totem_config($conf); >> + my $total_timeout_secs =3D >> + PVE::Corosync::calculate_total_timeout($totem_cfg, scalar(k= eys %$nodelist)); >> + if (my $msg =3D PVE::Corosync::get_timeout_warning($total_timeo= ut_secs)) { >> + warn "$msg\n"; >> + } >> + > > I can see why 'pvecm nodes' was chosen for this warning (since it's > related to the number of nodes), but I think 'pvecm status' would be > more appropriate, because it relates to the cluster health (perhaps > under 'Cluster Information')? We could also do both, but that's probably > overkill. Thinking about it again, I agree that `pvecm status` would be better. I suppose the `status` command is also used more often, making it more likely that users see the warning. I'll add it to the "Cluster Information" block for the v2. Thanks! > >> exec('corosync-quorumtool', '-l'); >> exit(-1); # should not be reached >> },