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
