From: Fiona Ebner <f.ebner@proxmox.com>
To: Daniel Kral <d.kral@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH-SERIES ha-manager 0/2] Negative Node Affinity Rules
Date: Wed, 25 Feb 2026 09:58:38 +0100 [thread overview]
Message-ID: <d215efe8-7af0-4610-9c86-be1a4cbad6f4@proxmox.com> (raw)
In-Reply-To: <DGNWTRPISDTW.X4VTV5QWO31L@proxmox.com>
Am 25.02.26 um 9:45 AM schrieb Daniel Kral:
> 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.
>>>
>>> * simple = without priority groups
>>>
>>>
>>> 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.
Waiting for demand is fine by me :)
>>> 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'.
Here too.
prev parent reply other threads:[~2026-02-25 8:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 13:35 Daniel Kral
2025-12-19 13:35 ` [pve-devel] [RFC PATCH ha-manager 1/2] rules: node affinity: add affinity property to node affinity rules Daniel Kral
2026-02-24 12:22 ` Fiona Ebner
2025-12-19 13:35 ` [pve-devel] [RFC PATCH ha-manager 2/2] rules: node affinity: implement negative " Daniel Kral
2026-02-24 12:22 ` Fiona Ebner
2026-02-25 8:32 ` Daniel Kral
2026-02-24 12:22 ` [pve-devel] [RFC PATCH-SERIES ha-manager 0/2] Negative Node Affinity Rules Fiona Ebner
2026-02-25 8:46 ` Daniel Kral
2026-02-25 8:58 ` Fiona Ebner [this message]
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=d215efe8-7af0-4610-9c86-be1a4cbad6f4@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.kral@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