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 187EE1FF15C for <inbox@lore.proxmox.com>; Fri, 27 Jun 2025 14:40:54 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id F0DCE140A1; Fri, 27 Jun 2025 14:41:27 +0200 (CEST) Message-ID: <b70b5d2e-7475-4e84-b428-3e0c1e70184e@proxmox.com> Date: Fri, 27 Jun 2025 14:41:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Friedrich Weber <f.weber@proxmox.com>, 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> <34932f67-87f4-4534-9aaa-0ba95e2c972d@proxmox.com> <7fb94369-d8b6-47c6-b36c-428db5bb85de@proxmox.com> Content-Language: en-US From: Daniel Kral <d.kral@proxmox.com> In-Reply-To: <7fb94369-d8b6-47c6-b36c-428db5bb85de@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/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)" _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel