[PATCH docs 06/18] ha-manager: crs: replace service term with HA resource

[Daniel Kral <d.kral@proxmox.com>]

'HA resource' is the preferred term for the HA-managed guests instead of
'service' and prefixing them with 'HA' makes the distinction between
HA-managed and HA-unmanaged resources clearer.

Signed-off-by: Daniel Kral <d.kral@proxmox.com>
---
 ha-manager.adoc | 53 +++++++++++++++++++++++++------------------------
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/ha-manager.adoc b/ha-manager.adoc
index a1b2210..aa2d362 100644
--- a/ha-manager.adoc
+++ b/ha-manager.adoc
@@ -1426,9 +1426,9 @@ crs: ha=static
 The change will be in effect starting with the next manager round (after a few
 seconds).
 
-For each service that needs to be recovered or migrated, the scheduler
+For each HA resource that needs to be recovered or migrated, the scheduler
 iteratively chooses the best node among the nodes that are available to
-the service according to their HA rules, if any.
+the HA resource according to their HA rules, if any.
 
 NOTE: There are plans to add modes for (static and dynamic) load-balancing in
 the future.
@@ -1436,18 +1436,18 @@ the future.
 Basic Scheduler
 ~~~~~~~~~~~~~~~
 
-The number of active HA services on each node is used to choose a recovery node.
-Non-HA-managed services are currently not counted.
+The number of active HA resources on each node is used to choose a recovery
+node. Non-HA-managed resources are currently not counted.
 
 Static-Load Scheduler
 ~~~~~~~~~~~~~~~~~~~~~
 
 IMPORTANT: The static mode is still a technology preview.
 
-Static usage information from HA services on each node is used to choose a
-recovery node. Usage of non-HA-managed services is currently not considered.
+Static usage information from HA resources on each node is used to choose a
+recovery node. Usage of non-HA-managed resources is currently not considered.
 
-For this selection, each node in turn is considered as if the service was
+For this selection, each node in turn is considered as if the HA resource was
 already running on it, using CPU and memory usage from the associated guest
 configuration. Then for each such alternative, CPU and memory usage of all nodes
 are considered, with memory being weighted much more, because it's a truly
@@ -1456,29 +1456,29 @@ more, as ideally no node should be overcommitted) and average usage of all nodes
 (to still be able to distinguish in case there already is a more highly
 committed node) are considered.
 
-IMPORTANT: The more services the more possible combinations there are, so it's
-currently not recommended to use it if you have thousands of HA managed
-services.
+IMPORTANT: The more HA resources the more possible combinations there are, so
+it's currently not recommended to use it if you have thousands of HA resources.
 
 
 CRS Scheduling Points
 ~~~~~~~~~~~~~~~~~~~~~
 
-The CRS algorithm is not applied for every service in every round, since this
-would mean a large number of constant migrations. Depending on the workload,
-this could put more strain on the cluster than could be avoided by constant
-balancing.
-That's why the {pve} HA manager favors keeping services on their current node.
+The CRS algorithm is not applied for every HA resource in every round, since
+this would mean a large number of constant migrations. Depending on the
+workload, this could put more strain on the cluster than could be avoided by
+constant balancing.
+That's why the {pve} HA manager favors keeping HA resources on their current
+node.
 
 The CRS is currently used at the following scheduling points:
 
-- Service recovery (always active). When a node with active HA services fails,
-  all its services need to be recovered to other nodes. The CRS algorithm will
-  be used here to balance that recovery over the remaining nodes.
+- HA resource recovery (always active). When a node with active HA resources
+  fails, all its HA resources need to be recovered to other nodes. The CRS
+  algorithm will be used here to balance that recovery over the remaining nodes.
 
 - HA group config changes (always active). If a node is removed from a group,
   or its priority is reduced, the HA stack will use the CRS algorithm to find a
-  new target node for the HA services in that group, matching the adapted
+  new target node for the HA resources in that group, matching the adapted
   priority constraints.
 
 - HA rule config changes (always active). If a rule emposes different
@@ -1501,13 +1501,14 @@ The CRS is currently used at the following scheduling points:
    rule, the HA stack will use the CRS algorithm to ensure that these HA
    resources are moved to separate nodes.
 
-- HA service stopped -> start transition (opt-in). Requesting that a stopped
-  service should be started is an good opportunity to check for the best suited
-  node as per the CRS algorithm, as moving stopped services is  cheaper to do
-  than moving them started, especially if their disk volumes reside on shared
-  storage. You can enable this by setting the **`ha-rebalance-on-start`**
-  CRS option in the datacenter config. You can change that option also in the
-  Web UI, under `Datacenter` -> `Options` -> `Cluster Resource Scheduling`.
+- HA resources stopped -> start transition (opt-in). Requesting that a stopped
+  HA resource should be started is an good opportunity to check for the best
+  suited node as per the CRS algorithm, as moving stopped HA resources is
+  cheaper to do than moving them started, especially if their disk volumes
+  reside on shared storage. You can enable this by setting the
+  **`ha-rebalance-on-start`** CRS option in the datacenter config. You can
+  change that option also in the Web UI, under `Datacenter` -> `Options` ->
+  `Cluster Resource Scheduling`.
 
 ifdef::manvolnum[]
 include::pve-copyright.adoc[]
-- 
2.47.3