From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id C54341FF0E1 for ; Mon, 13 Jul 2026 14:44:02 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 626AD21447; Mon, 13 Jul 2026 14:44:01 +0200 (CEST) Message-ID: <84f7a9d7-9103-4b37-8c5a-01aa19985a5a@proxmox.com> Date: Mon, 13 Jul 2026 14:43:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: David Riley Subject: Re: [PATCH docs v2 09/12] ha-manager: rules: use the correct article for terms starting with HA To: Daniel Kral , pve-devel@lists.proxmox.com References: <20260602100226.180071-1-d.kral@proxmox.com> <20260602100226.180071-10-d.kral@proxmox.com> Content-Language: en-US In-Reply-To: <20260602100226.180071-10-d.kral@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783946622837 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.273 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: T2DCAEBAXPWZ5YWDNNFOO2REFONP3ERF X-Message-ID-Hash: T2DCAEBAXPWZ5YWDNNFOO2REFONP3ERF X-MailFrom: d.riley@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 6/2/26 12:02 PM, Daniel Kral wrote: > The correct article four any term starting with "HA" is always 'an', > since the H is silent and therefore becomes a vowel sound. But is it really silent? Is it not because "Its name in English is aitch (pronounced /eɪtʃ/, plural aitches)" [0] And therefore it should be "an HA ..."? But no hard feelings just wondering. Otherwise it looks good to me. Consider this: Reviewed-by: David Riley [0] https://en.wikipedia.org/wiki/H > Signed-off-by: Daniel Kral > --- > changes since v1: > - new > > ha-manager.adoc | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/ha-manager.adoc b/ha-manager.adoc > index 7365ed0..d34916e 100644 > --- a/ha-manager.adoc > +++ b/ha-manager.adoc > @@ -719,9 +719,9 @@ on the same node. > Node Affinity Rules > ^^^^^^^^^^^^^^^^^^^ > > -By default, a HA resource is able to run on any cluster node, but a common > -requirement is that a HA resource should run on a specific node. That can be > -implemented by defining a HA node affinity rule to make the HA resource > +By default, an HA resource is able to run on any cluster node, but a common > +requirement is that an HA resource should run on a specific node. That can be > +implemented by defining an HA node affinity rule to make the HA resource > `vm:100` prefer the node `node1`: > > ---- > @@ -730,8 +730,8 @@ implemented by defining a HA node affinity rule to make the HA resource > > By default, node affinity rules are not strict, i.e., if there is none of the > specified nodes available, the HA resource can also be moved to other nodes. > -If, on the other hand, a HA resource must be restricted to the specified nodes, > -then the node affinity rule must be set to be strict. > +If, on the other hand, an HA resource must be restricted to the specified > +nodes, then the node affinity rule must be set to be strict. > > In the previous example, the node affinity rule can be modified to restrict the > resource `vm:100` to be only on `node1`: > @@ -823,8 +823,8 @@ separate nodes: > > Other than node affinity rules, resource affinity rules are strict by default, > i.e., if the constraints imposed by the resource affinity rules cannot be met > -for a HA resource, the HA Manager will put the HA resource in recovery state in > -case of a failover or in error state elsewhere. > +for an HA resource, the HA Manager will put the HA resource in recovery state > +in case of a failover or in error state elsewhere. > > The above commands created the following rules in the rules configuration file: > > @@ -905,9 +905,9 @@ Currently, HA rules are checked for the following feasibility tests: > resources as a negative HA resources affinity rule. That is, two or more HA > resources cannot be kept together and separate at the same time. > > -* An HA resource can only be part of a HA node affinity rule and a HA resource > - affinity rule at the same time, if the HA node affinity rule has a single > - priority class. > +* An HA resource can only be part of an HA node affinity rule and an HA > + resource affinity rule at the same time, if the HA node affinity rule has a > + single priority class. > > * The HA resources of a positive HA resource affinity rule can only be part of > a single HA node affinity rule at most.