From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9])
	by lore.proxmox.com (Postfix) with ESMTPS id 9BBC51FF16F
	for <inbox@lore.proxmox.com>; Tue, 24 Jun 2025 10:48:06 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id C91EF31611;
	Tue, 24 Jun 2025 10:48:38 +0200 (CEST)
Message-ID: <34932f67-87f4-4534-9aaa-0ba95e2c972d@proxmox.com>
Date: Tue, 24 Jun 2025 10:48:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 Thomas Lamprecht <t.lamprecht@proxmox.com>,
 "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>,
 Jillian Morgan <jillian.morgan@primordial.ca>
References: <20250620143148.218469-1-d.kral@proxmox.com>
 <8451d94e-176a-49e6-95ac-f25e7b4cfe9c@proxmox.com>
 <CALgSy_eOHi-XSL7m=z8HXegmpEUF0kbeqp9220XdK-X+Zaspcg@mail.gmail.com>
 <476c41123dced9d560dfbf27640ef8705fd90f11.camel@groupe-cyllene.com>
 <f2af9766-8f5b-458c-a131-ac34929d5424@proxmox.com>
Content-Language: en-US
From: Daniel Kral <d.kral@proxmox.com>
In-Reply-To: <f2af9766-8f5b-458c-a131-ac34929d5424@proxmox.com>
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.012 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] [RFC common/cluster/ha-manager/docs/manager v2
 00/40] HA colocation rules
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>

On 6/23/25 17:36, Thomas Lamprecht wrote:
> Am 20.06.25 um 19:45 schrieb DERUMIER, Alexandre:
>>>> 1) Having "location" and "colocation" rules is, I think, going to be
>>>> unnecessarily confusing for people. While it isn't too complicated to
>>>> glean
>>>> the distinction once having read the descriptions of them (and I had
>>>> to go
>>>> read the descriptions), they don't convey immediately how they
>>>> differentiate themselves from each other. I think the concepts are
>>>> better
>>>> described by something like "host-service affinity" (for positive or
>>>> negative affinity between service(s) and specific host(s)/Resource
>>>> Pools),
>>>> and "service-service affinity" (for positive or negative affinity
>>>> between
>>>> multiple services (where any relationship to specific hosts are
>>>> inconsequential or specifically undesirable).
>>
>> Hi, I had already said the same as comment of the v1 patch,
>>
>> I don't care personally, but all my customers coming from vmware, xcp-
>> ng, or cloud provider with ec2 or gcp, everybody in the industry is
>> using "affinity/antifinity host/vms" since 20years , and I'm pretty
>> sure that if they read the doc and some whitepaper/benchmark
>> comparaison  on the net (not even talking about chatgpt lol), they'll
>> think that the feature is not available.
> 
> IIRC Daniel took that nomenclature from pacemaker, albeit I mentioned
> that I really would not use that complex (!) project as example to
> follow, the PVE HA manager exists explicitly due to that being rather
> confusing and hard to configure for simple(r) use cases.
> 
> Anyhow, the names can be changed rather easily, and the input of you
> two certainly puts some additional weight for the "affinity" and
> "anti-affinity" terminology, so thanks for chiming in.

Correct, I got those from pacemaker, but I don't have any hard feelings 
changing them and will do so happily for the patch series, especially as 
it helps users grasp the concepts quicker without needing to consult the 
documentation just for understanding the names.

If it's not too much burden on the developer-side, I'd stick to 
"location" and "colocation" (positive/negative) in the code itself, as 
there short names are always a benefit IMO (with a notice what they're 
referred to on the user-facing side), but no hard feelings to change 
them there too if it's confusing otherwise.

If the following names are good to all as well, I'd change the rule 
names from/to:

"location" => "Service-Host Affinity"
"colocation" => "Service-Service Affinity"

and for colocation rules from/to:

"together" => "positive"
"separate" => "negative"

as suggested by @Jillian Morgan, but I'm very open for feedback on that. 
Especially if there's a good way to integrate the "affinity" and 
"anti-affinity" terminology here, but "Service-Host Affinity" rules 
don't have that yet (but could be a future addition if there are user 
requests for that).


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel