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 54D5B1FF136 for ; Mon, 20 Apr 2026 11:39:08 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 309D823875; Mon, 20 Apr 2026 11:39:08 +0200 (CEST) Message-ID: <28480320-ef59-462d-aecc-6a713ee3028b@proxmox.com> Date: Mon, 20 Apr 2026 11:39:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH cluster 1/5] add functions to determine warning level for high token timeouts To: =?UTF-8?Q?Michael_K=C3=B6ppl?= , pve-devel@lists.proxmox.com References: <20260330144321.321072-1-m.koeppl@proxmox.com> <20260330144321.321072-2-m.koeppl@proxmox.com> Content-Language: en-US From: Friedrich Weber In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776677860746 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.013 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: O4PFAWDZ3ZMRM6MVSL7D5PMNBNOHN334 X-Message-ID-Hash: O4PFAWDZ3ZMRM6MVSL7D5PMNBNOHN334 X-MailFrom: f.weber@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 20/04/2026 10:26, Michael Köppl wrote: > 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. Hm, "Reformation" reads a bit weird to me. Perhaps "recovery" is not so bad after all (a bit less esoteric than convergence or reformation), what about "membership recovery timeout"? The "membership" qualifier should make it reasonably clear that it's not the same as totem's "recovery" state.