[pve-devel] [RFC common/cluster/ha-manager/docs/manager v2 00/40] HA colocation rules

[Friedrich Weber]

Hi, as Daniel and I talked a bit off-list about the naming aspects, I'm
chiming in too.

On 24/06/2025 10:48, Daniel Kral wrote:
> 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.

I think, if it's not too awkward, it would be nicer to use the same
nomenclature in the user-facing interfaces (docs, config, cli, ...) and
in the internal code -- one never knows if some internal names "leak" to
the outside and may cause confusion.

> 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"

I'm not a huge fan of the "colocation" naming, especially because
"negative colocation" sounds like an oxymoron to me (because of the
association "co" = together but "negative" = not together), but that
might just be me.

Since the proposed "Service-Host Affinity" and "Service-Service
Affinity" are quite long: What about shortening those to "Host Affinity"
and "Service Affinity"? Since affinity rules are defined for HA
services, it should be clear that the subject is the "Service" in both
cases. Well, unless with this naming one could get the impression that
"host affinity" rules are defined for hosts, and "service affinity"
rules are defined for services, which would be wrong ...

And one last thought, I'd replace "Host Affinity" with "Node Affinity",
since I think in a cluster context we refer to the cluster hosts as
"nodes" much more often.

> 
> 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 at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
>