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 429951FF13B for ; Wed, 25 Feb 2026 09:45:24 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E0847302B8; Wed, 25 Feb 2026 09:46:17 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 25 Feb 2026 09:46:12 +0100 Message-Id: Subject: Re: [pve-devel] [RFC PATCH-SERIES ha-manager 0/2] Negative Node Affinity Rules From: "Daniel Kral" To: "Fiona Ebner" , "Proxmox VE development discussion" X-Mailer: aerc 0.21.0-38-g7088c3642f2c-dirty References: <20251219133643.295514-1-d.kral@proxmox.com> <7dc9c2c9-e355-4a40-a00f-abdd9c81b9e2@proxmox.com> In-Reply-To: <7dc9c2c9-e355-4a40-a00f-abdd9c81b9e2@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1772009155952 X-SPAM-LEVEL: Spam detection results: 0 AWL -1.042 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 1.113 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.358 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.659 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 Message-ID-Hash: 572F6E62E6MICZGJVGSUUP4HREKLY2KG X-Message-ID-Hash: 572F6E62E6MICZGJVGSUUP4HREKLY2KG X-MailFrom: d.kral@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 Tue Feb 24, 2026 at 1:22 PM CET, Fiona Ebner wrote: > Am 19.12.25 um 2:36 PM schrieb Daniel Kral: >> For larger HA clusters, specifying the nodes in simple* node affinity >> rules as opt-out (negative) instead of opt-in (positive) can make the >> rule set easier to follow and implement by users. >>=20 >> * simple =3D without priority groups >>=20 >>=20 >> There's no web interface integration yet, because I'm not entirely sure >> yet how to integrate it with the concept of priority groups for positive >> node affinity rules, which do not make sense in this context as the >> specified nodes will be removed from the effective node set. > > Wouldn't it be enough to not use/show the priority column when the > affinity is negative? > > If people need both, to exclude certain nodes and to prioritize certain > others, they can use two rules: > 1. a negative node affinity rule > 2. a non-strict positive node affinity rule with priorities Yes, this would only need some changes in the checks for node affinity rules to allow both types for a HA resource at once and a check that they do not contradict one another. I'm only contemplating about whether this could bite us later on if we allow those rule sets and should wait for the demand for this. >> As the conversion is pretty straightforward, we could even allow users >> to convert between positive and negative node affinity rules (e.g. when >> switching the affinity type in the web interface?). > > Limited to those without priorities I suppose ;) Right :). I'll see what makes sense in the web interface then, but it would probably be the easiest to restrict changing the type of the node affinity rule after it was created... Other options would be to either just reset the node selection or drop the node priorities and invert the selection if users change from 'positive' to 'negative'.