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

[Daniel Kral]

On 6/27/25 14:23, Friedrich Weber wrote:
> 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:
>> 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.

Right, I see that now too and with the shorter proposed names from you 
below here, I can see the same names used in the code as well.

The only thing I also pointed out in our brief discussion is that I 
liked the shortness of "positively colocated services" and "negatively 
colocated services" for services that are in a "colocation" relationship 
(which are declared by the colocation rules).

But I'll find another nice brief equivalent description for these with 
the new names as well, e.g., "services in positive affinity with service 
..." and "services in negative affinity with service ...". That could 
also work for the node affinity: "services in affinity to node ...".

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

I think those are even better names as already mentioned, as they 
quickly describe what they do while being short enough for mentioning 
them anywhere. Another point is that "HA Service" and "HA Resource" are 
synonyms to each other but "HA Resource" is mentioned much more often 
and is also the first name used in the documentation, so I'd go for

- "HA Node Affinity (Rules)"
- "HA Resource Affinity (Rules)"