From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id B781C1FF15C for ; Fri, 31 Oct 2025 11:01:23 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5E2CDDB24; Fri, 31 Oct 2025 11:01:57 +0100 (CET) Mime-Version: 1.0 Date: Fri, 31 Oct 2025 11:01:23 +0100 Message-Id: From: "Daniel Kral" To: "Thomas Lamprecht" , "Proxmox VE development discussion" , "Daniel Kral" X-Mailer: aerc 0.21.0-10-gf12c391cb5b4 References: <20250909083539.39675-1-d.kral@proxmox.com> <20250909083539.39675-6-d.kral@proxmox.com> <9fc563b3-6df0-4f9e-80df-6c1834073c33@proxmox.com> In-Reply-To: <9fc563b3-6df0-4f9e-80df-6c1834073c33@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1761904868929 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.014 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH ha-manager v2 05/18] rules: add merged positive resource affinity info in global checks X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On Wed Sep 10, 2025 at 7:35 PM CEST, Thomas Lamprecht wrote: > Am 09.09.25 um 10:36 schrieb Daniel Kral: >> The node affinity and positive resource affinity rule subset is checked >> whether the HA resources in a positive resource affinity rule are in >> more than one node affinity rule in total. >> >> This check has the assumption that each positive resource affinity >> rule's resource set is disjoint from each other, but this is only done >> in the later transformation stage when positive resource affinity with >> overlapping HA resources in them are merged to one rule. >> >> For example, the following inconsistent rules are not pruned: >> >> - positive resource affinity rule between vm:101 and vm:102 >> - positive resource affinity rule between vm:102 and vm:103 >> - node affinity rule for vm:101 on node1 >> - node affinity rule for vm:103 on node3 > > This is only a real problem if both node affinity rules are configured > to be strict. Your test case (and FWICT code) acts that way, so mostly > relevant for the commit message to avoid potential confusion about what > rules get/needs to be pruned. Can be improved on applying though, no need > for a v3 just for that, just wanted to note it to avoid forgetting it in > case I do not get around to finish review here soonish. I assumed this to be true too when I read it in September, but as I reviewed this again for sending a new revision for this series now I noticed that it also prunes non-strict node affinity rules. We follow the priority classes quite strictly for node affinity rules/HA groups (for both non-strict and strict ones) with only respecting the highest nodes in the highest priority class. As the non-member nodes for non-strict node affinity rules are added with priority -1, it depends on whether none of the higher priority nodes are online and so we cannot verify here whether this will be the case. A more revealing example would be a cluster with the 3 nodes node1, node2, and node3 and the following rules (based on the example above): - positive resource affinity rule between vm:101 and vm:102 - positive resource affinity rule between vm:102 and vm:103 - non-strict node affinity rule for vm:101 on node1:3,node2:2 - non-strict node affinity rule for vm:103 on node3:3,node2:2 This rule set would only be consistent if node1 and node3 would be both down and would never fallback to node3 and node1 respectively as then the whole cluster must be offline. I'll clarify this in the commit message and test cases for the v3. FWIW it might be worth to check out to loosen up this behavior a bit with counting priorities as weights, as we briefly talked off-list as far as I can remember, but as I've seen at least a few users who depend on the current behavior we'd need to make this a (per-rule?) flag. >> >> Therefore build the same disjoint positive resource affinity resource >> sets as the merge_connected_positive_resource_affinity_rules(...) >> subroutine, so that the inconsistency check has the necessary >> information in advance. >> _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel