From: "Michael Köppl" <m.koeppl@proxmox.com>
To: "Friedrich Weber" <f.weber@proxmox.com>,
"Michael Köppl" <m.koeppl@proxmox.com>,
pve-devel@lists.proxmox.com
Subject: Re: [PATCH cluster 1/5] add functions to determine warning level for high token timeouts
Date: Mon, 20 Apr 2026 10:28:14 +0200 [thread overview]
Message-ID: <DHXU9FLPOIKK.25YB1OD27GQ8Q@proxmox.com> (raw)
In-Reply-To: <a0d4baa9-8e7e-4cc5-8117-c8cf0bfc74b0@proxmox.com>
On Fri Apr 17, 2026 at 10:33 AM CEST, Friedrich Weber wrote:
[snip]
>>
>> +sub calculate_total_timeout {
>
> I think "total timeout" is a little too vague, especially because it's
> also user-facing. I don't think totem/corosync have a term for "sum of
> token and consensus timeout", and "sum of token and consensus timeout"
> is a too long. Perhaps something like "recovery timeout" -- though not
> perfect because "Recovery" is a specific state in the totem state
> machine. Maybe "membership convergence timeout" (though that's a bit
> long and obscure)?
Thanks for having a look at this and for your feedback. I agree that the
naming is a bit too vague, though I really wasn't sure what else to name
it. I think calculate_membership_convergence_timeout could work. As an
alternative suggestion, what do you think of
calculate_cluster_reformation_timeout? Of course that's also a more
"verbose" name, but I think it describes the effects of the timeout
quite well.
>
>> + my ($totemcfg, $node_count) = @_;
>> +
>> + my $token_timeout = $totemcfg->{token} // 3000;
>> + my $token_coefficient = $totemcfg->{token_coefficient} // 650;
>> +
>> + my $expected_token_timeout = $token_timeout;
>> + if ($node_count > 2) {
>> + $expected_token_timeout += ($node_count - 2) * $token_coefficient;
>> + }
>> +
>> + my $expected_consensus_timeout = $totemcfg->{consensus} // $expected_token_timeout * 1.2;
>> + return ($expected_token_timeout + $expected_consensus_timeout) / 1000.0;
>> +}
>> +
>> +sub get_timeout_warning_level {
>> + my ($total_timeout_secs) = @_;
>> +
>> + if ($total_timeout_secs > 50) {
>> + return 'change-strongly-recommended';
>
> I realize I'm the source of these numbers :) But since >50 is actually
> pretty bad already, if we phrase it as "strongly recommended" we can
> probably go for a slightly lower number:
>
> - > 45: change-strongly-recommended
> - > 40: change recommended
> - > 30: optimize
will lower them for a v2, thanks! :) I'd already wondered about the
thresholds when I implemented this, but thought it'd make sense to start
with the values from the bugzilla.
>
>> + } elsif ($total_timeout_secs > 40) {
>> + return 'change-recommended';
[snip]
next prev parent reply other threads:[~2026-04-20 8:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 14:43 [PATCH cluster/manager 0/5] add warning messages for high token timeouts in clusters Michael Köppl
2026-03-30 14:43 ` [PATCH cluster 1/5] add functions to determine warning level for high token timeouts Michael Köppl
2026-04-17 8:33 ` Friedrich Weber
2026-04-20 8:28 ` Michael Köppl [this message]
2026-04-20 9:39 ` Friedrich Weber
2026-04-20 13:50 ` Michael Köppl
2026-04-17 8:33 ` Friedrich Weber
2026-03-30 14:43 ` [PATCH cluster 2/5] pvecm: warn users of high token timeouts when using nodes command Michael Köppl
2026-04-17 8:33 ` Friedrich Weber
2026-04-20 13:33 ` Michael Köppl
2026-03-30 14:43 ` [PATCH cluster 3/5] api: add token timeout and warning level to cluster join info Michael Köppl
2026-04-17 8:33 ` Friedrich Weber
2026-03-30 14:43 ` [PATCH manager 4/5] ui: cluster info: move initialization of items to initComponent Michael Köppl
2026-04-17 8:33 ` Friedrich Weber
2026-03-30 14:43 ` [PATCH manager 5/5] ui: cluster info: warn users of high token timeout in join info Michael Köppl
2026-04-17 8:34 ` Friedrich Weber
2026-04-17 8:33 ` [PATCH cluster/manager 0/5] add warning messages for high token timeouts in clusters Friedrich Weber
2026-04-20 16:44 ` superseded: " Michael Köppl
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=DHXU9FLPOIKK.25YB1OD27GQ8Q@proxmox.com \
--to=m.koeppl@proxmox.com \
--cc=f.weber@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