]> git.proxmox.com Git - pve-ha-manager.git/blobdiff - README
build: bump compat level to 10
[pve-ha-manager.git] / README
diff --git a/README b/README
index 82b7f2659f36292dd352ab498b0753af79b7164c..1c5177f16e81fba2df819a4e469cd03323ac89a4 100644 (file)
--- a/README
+++ b/README
@@ -17,14 +17,17 @@ In future, we want to make HA easier for our users, and it should
 be possible to move to newest corosync, or even a totally different 
 cluster stack. So we want:
 
-- possible to run with any distributed key/value store which provides
+- possibility to run with any distributed key/value store which provides
   some kind of locking with timeouts (zookeeper, consul, etcd, ..) 
 
 - self fencing using Linux watchdog device
 
 - implemented in Perl, so that we can use PVE framework
 
-- only works with simply resources like VMs
+- only work with simply resources like VMs
+
+We dropped the idea to assemble complex, dependend services, because we think
+this is already done with the VM abstraction.
 
 = Architecture =
 
@@ -38,7 +41,7 @@ The Proxmox 'pmxcfs' implements this on top of corosync.
 === Watchdog ===
 
 We need a reliable watchdog mechanism, which is able to provide hard
-timeouts. It must be guaranteed that the node reboot withing specified
+timeouts. It must be guaranteed that the node reboots within the specified
 timeout if we do not update the watchdog. For me it looks that neither
 systemd nor the standard watchdog(8) daemon provides such guarantees.
 
@@ -49,7 +52,7 @@ provides that service to several other daemons using a local socket.
 
 == Self fencing ==
 
-A node needs to aquire a special 'ha_agent_${node}_lock' (one separate
+A node needs to acquire a special 'ha_agent_${node}_lock' (one separate
 lock for each node) before starting HA resources, and the node updates
 the watchdog device once it get that lock. If the node loose quorum,
 or is unable to get the 'ha_agent_${node}_lock', the watchdog is no
@@ -60,7 +63,7 @@ This makes sure that the node holds the 'ha_agent_${node}_lock' as
 long as there are running services on that node.
 
 The HA manger can assume that the watchdog triggered a reboot when he
-is able to aquire the 'ha_agent_${node}_lock' for that node.
+is able to acquire the 'ha_agent_${node}_lock' for that node.
 
 === Problems with "two_node" Clusters ===
 
@@ -95,6 +98,10 @@ Most other service types requires the service to be stopped, and then
 restarted at the other node. Stopped services are moved by the CRM
 (usually by simply changing the service configuration).
 
+=== Service ordering and colocation constarints ===
+
+So far there are no plans to implement this (although it would be possible).
+
 === Possible CRM Service States ===
 
 stopped:      Service is stopped (confirmed by LRM)
@@ -107,12 +114,14 @@ started:      Service is active an LRM should start it asap.
 fence:        Wait for node fencing (service node is not inside
              quorate cluster partition).
 
+freeze:       Do not touch. We use this state while we reboot a node,
+             or when we restart the LRM daemon.
+
 migrate:      Migrate (live) service to other node.
 
 error:        Service disabled because of LRM errors.
 
 
-
 == Local Resource Manager (class PVE::HA::LRM) ==
 
 The Local Resource Manager (LRM) daemon runs one each node, and