public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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]




  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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal