]> git.proxmox.com Git - pve-ha-manager.git/commit
test: cover case where all service get removed from in-progress fenced node
authorThomas Lamprecht <t.lamprecht@proxmox.com>
Mon, 17 Jan 2022 11:25:35 +0000 (12:25 +0100)
committerThomas Lamprecht <t.lamprecht@proxmox.com>
Wed, 19 Jan 2022 12:48:21 +0000 (13:48 +0100)
commitca2e547a7662467f9a08c54fa15b46825e3702e6
tree93222d34e39e2d49d0a8ff7dceaafa34c450137c
parent1b21e7e651602defde46d42b7340d1381379a73c
test: cover case where all service get removed from in-progress fenced node

this test's log is showing up two issues we'll fix in later commits

1. If a node gets fenced and an admin removes all services before the
   fencing completes, the manager will ignore that node's state and
   thus never make the "fence" -> "unknown" transition required by
   the state machine

2. If a node is marked as "fence" in the manager's node status, but
   has no service, its LRM's check for "pending fence request"
   returns a false negative and the node start trying to acquire its
   LRM work lock. This can even succeed in practice, e.g. the events:
    1. Node A gets fenced (whyever that is), CRM is working on
       acquiring its lock while Node A reboots
    2. Admin is present and removes all services of Node A from HA
    2. Node A booted up fast again, LRM is already starting before
       CRM could ever get the lock (<< 2 minutes)
    3. Service located on Node A gets added to HA (again)
    4. LRM of Node A will actively try to get lock as it has no
       service in fence state and is (currently) not checking the
       manager's node state, so is ignorant of the not yet processed
       fence -> unknown transition
    (note: above uses 2. twice as those points order doesn't matter)

    As a result the CRM may never get to acquire the lock of Node A's
    LRM, and thus cannot finish the fence -> unknown transition,
    resulting in user confusion and possible weird effects.

I the current log one can observe 1. by the missing fence tries of
the master and 2. can be observed by the LRM acquiring the lock while
still being in "fence" state from the masters POV.

We use two tests so that point 2. is better covered later on

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
12 files changed:
src/test/test-service-command8/README [new file with mode: 0644]
src/test/test-service-command8/cmdlist [new file with mode: 0644]
src/test/test-service-command8/hardware_status [new file with mode: 0644]
src/test/test-service-command8/log.expect [new file with mode: 0644]
src/test/test-service-command8/manager_status [new file with mode: 0644]
src/test/test-service-command8/service_config [new file with mode: 0644]
src/test/test-service-command9/README [new file with mode: 0644]
src/test/test-service-command9/cmdlist [new file with mode: 0644]
src/test/test-service-command9/hardware_status [new file with mode: 0644]
src/test/test-service-command9/log.expect [new file with mode: 0644]
src/test/test-service-command9/manager_status [new file with mode: 0644]
src/test/test-service-command9/service_config [new file with mode: 0644]