cleanup backup & mounted locks after recovery (fixes #1100)

This cleans up the backup and mounted locks after a service is
recovered from a failed node, else it may not start if a locked
action occurred during the node failure.
We allow deletion of backup and mounted locks as they are secure
to do so if the node which hosted the locked service is now fenced.
We do not allow snapshot lock deletion as this needs more manual
clean up, also they are normally triggered manually.
Further ignore migration locks for now, we should over think that but
as its a manual triggered action for now it should be OK to not
auto delete it.

We do cannot remove locks via the remove_lock method provided by
PVE::AbstractConfig, as this method is well behaved and does not
allows removing locks from VMs/CTs located on another node.  We also
do not want to adapt this method to allow arbitrary lock removing,
independent on which node the config is located, as this could cause
missuse in the future. After all one of our base principles is that
the node owns its VMs/CTs (and there configs) and only the owner
itself may change the status of a VM/CT.

The HA manager needs to be able to change the state of services
when a node failed and is also allowed to do so, but only if the
node is fenced and we need to recover a service from it.

So we (re)implement the remove lock functionality in the resource
plugins.
We call that only if a node was fenced, and only *previous* stealing
the service. After all our implication to remove a lock is that the
owner (the node) is fenced. After stealing it we already changed
owner, and the new owner is *not* fenced and thus our implication
does not hold anymore - the new owner may already do some stuff
with the service (config changes, etc.)

Add the respective log.expect output from the added test to enable
regression testing this issue.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add possibility to simulate locks from services

In the real PVE2 environment locks can be leftover if a node fails
during an locked action like for example backups.
A left over lock may hinder the service to start on another node,
allow our test environment to simulate such events.

Also add two regression tests without the expected log files.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

remove state transition from error to fence state

Remove the possible transition from error to fence state. The error
state is an end state and mustn't be left by some automatic action
but on manual intervention!

This also allows us later on to place a service which is not
recoverable from the fence in the error state without generating
and endless loop of state changes.

Add a regression test for a failed node with a service in error
state.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

don't regression test when building the simulator package

we did the tests already when building the HA manager package so
if those did not fail the one from the HA manager simulator will
certainly not fail too so do not waste time running them again.

This has the small drawback that if anyone just builds the simulator
package through `make simdeb` the test won't be run at all for the
build package, this is seldom the case and can be worked around -
i.e. just use the all make target or run the tests manual.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add missing cleanup for fence config regression testsuite

we did not clean up the generated file from the fence config parser
self check, add them to the clean target.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add missing use clause in CT resource class

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-34

fix race condition on slow resource commands in started state

When we fixed the dangling state machine - where one command request
from the CRM could result in multiple executes of said command by
the LRM - by ensuring in the LRM that UID identified actions get
only started once per UID (except the stop comand) we introduced a
bug which can result in a lost LRM result from an failed service
start.

The reason for this is that we generated a new UID for the started
state every CRM turn, so that a service gets restarted if it
crashes. But as we do this without checking if the LRM has finished
our last request we may loose the result of this last request.
As an example consider the following timeline of events:
1. CRM request start of Service 'ct:100'
2. LRM starts this request, needs a bit longer
3. Before LRM worker finishes the CRM does an iteration and
   generates a new UID for this service
4. The LRM worker finishes but cannot write back its result as
   the UID doesn't exists anymore in the managers service status.
5. The CRM gets another round and generates a new UID for 'ct:100'
6. The cycle begins again, the LRM always throws away its last
   result as the CRM wrongfully generated an new command

This loss of the result is problematic if it was an erroneous one,
because then it result in a malfunction of the failure restart and
relocate policies.

Fix this by checking in the CRM if the last command was processed by
the LRM, so simply check if a $lrm_result exists.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

use new repoman for upload target

bump version to 1.0-33

allow empty json status files

Else we crash fatally on an existing but empty status file like
/etc/pve/manager_status , reproducible with:
$ > /etc/pve/ha/manager_status

We do not want to catch arbitrary errors as then users cannot
reconstruct what happened in the event of an error.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

refactor select_service_method

factor out the default group generation and the priority group
generation.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

relocate policy: try to avoid already failed nodes

In the event that the cluster remains stable from the HA view
point (i.e. no LRM failures, no service changes) and a service
with a start error relocate policy configured fails to start
it will cycle between two nodes back and forth, even if other
untried nodes (with a possibility that the service could be
started there) would be available.
The reason for this behavior is that if more than one node is
possible we select the one with the lowest active service count
to minimize cluster impact a bit.

As a start of a service failed on a node a short time ago it
probably will also fail the next try (e.g. storage is offline),
whereas an untried node may have the chance to be fully
able to start the service, which is our goal.

Fix that by excluding those already tried nodes from the top
priority node list in 'select_service_node' if there are other
possible nodes to try, we do that by giving select_service_node
a array of the already tried nodes, those then get deleted from the
selected top priority group.
If there is no node left after that we retry on the current node and
hope that another node becomes available.
While not ideal this a situation caused by the user with a high
probability as our default start error relocation setting is one
relocate try.

If all tries fail we place the service in the error state, the
tried nodes entry gets cleanup after an user triggers an error
recovery by disabling the service, so the information of the tried
nodes stays in the manager status until then.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

improve logging

fix indentation

Manager: record tried node on relocation policy

Instead of counting up an integer on each failed start trial, record
the already tried nodes. We can then use the size of the tried nodes
record array as 'try count' and achieve so the same behaviour as with
the 'relocate_trial' hash earlier.

Log the tried nodes after the service started or if it could not be
started at all, so an admin can follow the behaviour and investigate
the reason of the failure on a specific node.

This prepares us also for a more intelligent recovery node selection,
as we can skip already tried nodes from the current recovery cycle.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

cleanup manager status on start

Cleanup the manager state in a general way if we get promoted to
manager. This safes us code as instead of having to check all
deprecated entries and delete them, each one extra, we just safe the
state part needed to change master without loosing any result of the
manager status and just delete the rest.
This would include the following keys:
* service status: as it may contain unprocessed results
* manager_node: this is set only once before this cleanup so do not
  delete it.

Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

FenceConfig: assert that device priorities are unique

Each device priority must be unique to guarantee a deterministic
execution of the configured devices.
Else we cannot decide in which order we should write the devices to
the config file.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

HA/Config: add write_fence_config helper

We have already an helper for reading, so just add one for writingr,
it is helpful for the HW Fence API integration.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

adapt test output for better readability

To match the one from the parser self test and to separate each test
with a new line, for better readability.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add parser self check regression test

This test does a read -> write -> read cycle and then checks if the
config generated from the first read and the config generated from
the second read are equivalent (semantically).

This tests mainly the FenceConfig::write_config method, the
parse_config method gets checked with the already implemented config
regression tests.

To compare both configs we add a deep object compare method,
it can compare Objects with arbitrary nested data structures from the
types: hash, array and scalar.
It makes an depth first search with some early abortion checks on
the roots of subtrees (i.e. is the length and type the same).

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

FenceConfig: fix write_config

This problems where detected with the new fence config parser self
check tests introduced as a later patch here.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

sort some more keys for regression test determinism

Else i run in problems with later introduced regression tests

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Fence: rewrite class

A rather big cleanup of parts I already had in a separate branch and
new changes which arose from further testing and evaluating the
current code.

The class is currently not used and thus the rewrite should not be
problematic, I also tested it with my HW fencing branch and it still
works as previously.

Changes:
* add constructor and safe state in class object instead of global
  vars
* check_jobs was now split up in collect_finished_workers (which may
  be later factored out as LRM uses a similar worker implementation)
  and in check_worker_results.
* change method name from start_fencing to run_fence_jobs, it will
  check the active workers if the node has already a fence job
  deployed or else start fencing for this node
* fix bugs in process_fencing where if multiple parallel device
  succeeded at once only one was counted
* restrict waitpid to fence_job worker pids (instead of -1) else
  we could get some pretty nasty side effects
* remove 'reset_hard', 'reset' and 'bailout', they are replaced by
  kill_and_cleanup_jobs
* some comment and formatting changes

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

update changelog

send email on fence failure and success

Fencing is something which should not happen often in the real world
and has most time a really bad cause, thus send a email when
starting to fence a node and on success to root@localhost to inform
the cluster admin of said failures so he can check the hardware and
cluster status as soon as possible.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Env: add sendmail

Can be used to sen mails to the admin on certain important events
Do not log sent mails in regressions tests but in the simulator

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Sim/Hardware: check if testdir exists

avoids stranges error like "could not open dir/group.tmp.PID"

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Manager, LRM: sort service keys for deterministic tests

Else we the regression test produce a indeterministic output.
As the hashs would else be traversed in random order it makes no
real difference for the PVE2 environment, so just sort keys when we
add them to the cluster or spawn resource agent workers to avoid
that problem.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-32

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

use correct verify function for ha-group-node-list

We use pve_verify_nodename but we expect here a value with the
syntax: nodename[:priority]
So if someone used the optional priority this failed unecessarily.

select_service_node in the Manager class expects this value and
splits it itself into nodename and priority so we can just return
it if it matches the ha-group-node-list format.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-31

selcet_service_node: include all online nodes in default group

This changes the behaviour of selecting the node a service should
run on when try_next is true.
If no group is set all online nodes will be used as default group.

If the user sets a group this has no changes in behaviour.

If no group is set and the current_node is available and try_next
is false this has also no changes, it behaves the same as in the
past.
If we set try_next and the service has no group set this allows
a new node to be selected if possible. Fixes the relocation policy
on services with no group set, which else will never be relocated
to another group.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add relocate policy test on service without node

Test mainly the behaviour of the select_service_node method when
the service is in no group and the try_next parameter is true,
this happens when the relocate policy is executed.

has no log.expected yet

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

LRM: do not count erroneous service as active

Fixes an infinite hang on updating or restarting a nodes LRM when a
service within the error state is located on it.

We fix that by not counting those services towards the "active
service count" as an service in an error state is *not* managed by
HA, thus also not active.

As we use the active service count in three places this change has
the following effects:

* when determining if we should try to acquire our agent_lock and
make the state transition from wait_for_agent_lock => active. Here
its safe as we cannot do anything with the erroneous states anyhow,
and as the only way to move out from error state is disabling the
service (thus marking it as stopped) has the result that it still
is not counted as active, as we skip stopped also, so this is safe
and also wanted.

* when restarting the LRM to see if it has frozen all active
services and thus it's allowed to finish the restart. This is the
primary intent of this patch as it allows the LRM to restart safely
witouth hanging forever (and then be killed by systemd which results
in a watchdog node reset).

* when shutting down a LRM in lost_agent_lock state, here it has the
effect that with this patch the node won't get shot by its watchdog
if it has erroneous services but not active ones, this is not only
save but wanted. It makes no sense letting the watchdog trigger when
we have no active services besides the one in the error state, as
when restarting it does not make anything better (error services
won't get touched after all).

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

fix relocate/restart trial count leak on service deletion

If a service gets remove from HA remove also its relocate and
restart trial count from LRM status and manager_status, else it
never gets deleted (leak).

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

remove remaining references to $fence_delay

bump version to 1.0-30, set RELEASE=4.2

Env: allow debug logging

this can be helpful if someone wants to quickly add debug output for
a real world or simulator test, witout touching the regression tests

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

move fence_delay to node status

we only need it there also helps us variable reuse in next patch

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-29

Resources: deny setting nonexistent group

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

fix typo: s/servive/service/

bump version to 1.0-28

Config: add get_service_status method

fix man page path

bump version to 1.0-27

use pve-doc-generator to generate man pages

add Fence class for external fence devices

This class provides methods for starting and checking the current
status of a fence job.

When a fence job is started we execute a fence agent command.
If we can fork this happens in forked worker, which can be multiple
processes also, when parallel devices are configured.

When a device fails to successfully fence a node we try the next
device configured, or if no device is left we tell the CRM and let
him decide what to do.

If one process of a parallel device fails we kill the remaining
processes (with reset_hard) and try the next device as we want to
avoid a partial fenced node.

The current running fence jobs can be picked up (if env. allows
forking) and processed by calling the process_fencing method.

If the CRM (which should handle the fencing) looses its lock
bail_out can be called to kill all currently running fencing
processes and reset the fencing status of all nodes.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Env, HW: add HW fencing related functions

This adds three methods to hardware fencing related functions:
* read_fence_config
* fencing_mode
* exec_fence_agent

'read_fence_config' allows to create a common code base between the
real world and the test/sim world regarding fencing a bit easier.
In PVE2 it parses the config from /etc/pve/ha/fence.cfg and in
the Sim method it parses the config from testdir/status/fence.cfg.

The 'fencing_mode' method checks respective to the callee's
environment if hardware fencing is enabled and returns the wanted
mode:

* PVE2: if the datacenter.cfg key 'fencing' is set then it will be
        used, else we use 'watchdog' as default.

* Sim: if the cfg exist and at least one device is configured we use
       'hardware' fencing, else we default to 'watchdog'.

For the simulator we should make also a option to turn HW fencing
off and on independent if devices are configured when we implement
HW fencing for it, but that is not really needed for now.

'exec_fence_agent' executes, as the name suggests, environment
specific a fence agent.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-26

status: show added but not yet active services

If the CRM is dead or not active yet and we add a new service, we do
not see it in the HA status. This can be confusing for the user as
it is queued for adding but does not shows up, so lets show those
services also.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

use split_args and shellquote instead of strange regex

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

status: mark CRM as idle if no service is configured

This should avoid confusion if we remove all service from the CRM,
as else we would always see "old timestamp -dead?" in the status.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

FenceConfig: remove strange __die()

add FenceConfig class for external fencing devices

Add a FenceConfig class which includes methods to parse a config
file for fence devices in the format specified by dlm.conf, see the
Fencing section in the dlm.conf manpage for more details regarding
this format.

With this we can generate commands for fencing a node from the
parsed config file.

We assume that the fence config resides in the pve cluster fs under
/etc/pve/ha/fence_devices.cfg for the PVE2 environment.
But we can give parse_config and arbitary raw string, this allows
to use fencing also in (regression) tests and simultaion.

A simple regression testing script for the config generation was
also added. This test mainly the parse_config and get_commands
methods. A config file can be passed as argument, else we cycle
through the *.cfg files in the fence_cfgs folder.

Example configs for regression testing are located in
src/test/fence_cfgs directory
Note that not all files are valid examples as some are used to check
the error handling of the parser!

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-25

Use config_file from PVE::QemuConfig

update after refactoring

LXC refactoring

call config_file in PVE::LXC::Config instead of PVE::LXC

simulator: install all virtual resources

we include it in the source and we also want to allow to use it

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-23

fix infinite started <=> migrate cycle

If we get an 'EWRONG_NODE' error from the migration we have no sane
way out. If we place it then in the started state we also get the
'EWRONG_NODE' error again and it even will place the service in
the migration state again (when it's not restricted by a group) and
thus result in an infinite started <=> migrate cycle.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add test for infinite started <=> migrate cycle

exec_resource_agent: process error state early

We want to give the error state priority over EWRONG_NODE as a
service may be in the error state because of EWRONG_NODE

Change the error message a bit as we now can not distinguish
running and stopped services.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

avoid out of sync command execution in LRM

We are only allowed to execute any command once as else we
may disturb the synchrony between CRM and LRM.

The following scenario could happen:
schedule CRM: deploy task 'migrate' for service vm:100 with UID 1234
schedule LRM: fork task wit UID 123
schedule CRM: idle as no result available yet
schedule LRM: collect finished task UID and write result for CRM
      Result was an error
schedule LRM: fork task UID _AGAIN_
schedule CRM: processes _previous_ erroneous result from LRM
      and place vm:100 in started state on source node
schedule LRM: collect finished task UID and write result for CRM
      This time the task was successful and service is on
      target node, but the CRM know _nothing_ of it!
schedule LRM: try to schedule task but service is not on this node!
=> error

To fix that we _never_ execute two exactly same commands after each
other, exactly means here that the UID of the actual command to
queue is already a valid result.

This enforces the originally wanted SYN - ACK behaviour between CRM
and LRMs.

We generate now a new UID for services who does not change state
the one of the following evaluates to true:
* enabled AND in started state

This ensures that the state from the CRM holds in the LRM and thus,
for example, a killed VM gets restarted.

Note that the 'stopped' command is an exception, as we do not check
its result in the CRM (thus no race here) and we always want to
execute it (even when no CRM is active).

do not pass ETRY_AGAIN back to the CRM

This is simply not necessary. Everything can be done inside the LRM.

crm: avoid 'started' state after relocate if serive is disabled

fix 'uninitialized value' on online node usage computation

This fixes a bug introduced by commit 9da84a0 which set the wrong
hash when a disabled service got a migrate/relocate command.

We set "node => $target", while our state machine could handle that
we got some "uninitialized value" warnings when migrating a disabled
service to an inactive LRM. Better set "target => $target"

Further add a test for this scenario.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

fix some log formatting

First remove trailing whitespace from log messages on state changes
This needs to touch some regression test, but with no change in
semantics.

Second add a missing paranthese on the "fixup service location"
message. This needs no regression test log.expect changes.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-22

fix 'change_service_location' misuse and recovery from fencing

First rename the change_service_location method from the environment
to an more fitting name, 'steal_service'.

The 'change_service_location' from the virtual hardware class stays
at it is, because there the name fits (those function have not the
same meaning, so it's good that they named different now).

As we misused the config steal method (former
change_service_location) in the stopped state to process the
services from fenced nodes we need another way now.

This is achieved through the private method 'recover_fenced_service'
which is now the only place who has the right to steal a service
from an node.
When a node was successfully fenced we no longer change its services
state to 'stopped', rather we drop that hack and search a new node
in 'recover_fenced_service', if found we the steal the service and
move it to from the fenced to the new (recovery) node and place it
there in the 'started' state, after that the state machine is able
to handle the rest.

If we do not find a node we try again next round as that is better
then placing it in the error state, because so we have still a
chance to recover, which we do not have with the error state.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add VirtFail resource and use it in new regression tests

This resource let us test a defined failiure behaviour ofi services.

Through the VMID we define how it should behave, with the folowing
rules:

When the service has the SID "fa:abcde" the digits a - e mean:

a - no meaning but can be used for differentiating similar resources
b - how many tries are needed to start correctly (0=default)
c - how many tries are needed to migrate correctly (0=default)
d - should shutdown be successful (0 = yes, anything else no)
e - return value of $plugin->exists() defaults to 1 if not set

a,b,c should always be set even if b and c have defaults (makes test
purpose clearer)
d and e

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

truncate log level in regression tests

this is mainly for formatting (prettiness) purpose but helps when
going through an output of a test.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

improve relocation policy code in manager and LRM

Else a few branches would not be taken and the behaviour wasn't
quite straightforward.

Only increment tries if we really retry and log retries

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

replace can_fork with get_max_workers

This patch implements the use of the new max_workers setting from
the datacenter.cfg.

Adding a 'get_max_worker' method to the enviornment allows us to
do that and to replace 'can_fork' with that method.

can_fork isn't needed anymore as get_max_worker may simply return 0
to signal that the respective enviornment can not fork.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

improve verbosity of API status call

Display the state of a LRM when it is not in the "active" state
and has some service configured.

This should reduce confiusion when the LRM is active but still has
to wait for its lock. In such a case the user only sees that it's
active and could think it's malfunctioning because no action
happens.

Also displays the LRM mode, so that we can see when we restart the LRM.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>

cleanup: remove resources_config_exists

replace service_config_exists with has_services

Remove the "service_config_exists" method from the Environment class
and replace it with a new method in PVE::HA::Tools.
First we do not need this method in the Environment class and second
this can be reused more for checking if a note has any service
configured.

This moves the regression test also a little closer to the real
world behaviour (while maintaining determinism).

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

fix inf. loop error on orphaned workers

bump version to 1.0-21

Fix postinstall script not removing watchdog-mux.socket

watchdog-mux.socket was removed in f8a3fc80af but the
postinstall script used -e instead of -L to test for the
symlink, which fails since the destination is already
removed at that point.

Use -L and remove the dead symlink if it exists.

Reported-by: Alexandre Derumier <aderumier@odiso.com>

bump versionm to 1.0-20

move upid_wait from PVE2 env to HA::Tools

We can now use the new wait_upid from PVE::Tools and we output a
"Task still active" every five seconds instead of every second,
so we trash the log less.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

fix check if a resource migrated correctly

Move the check from exec_resource_agents to the migrate method of
the resource plugins so that we may delete the traces from the
additional method 'is_on_node' which was intended for this
purpose.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add after_fork method to HA environment and use it in LRM

As both the realtime simulator and the real world Environment can
fork but we only need to clean up after a fork in the real world
introduce a after_fork method

In PVE2 it closes the inherited INotify fd and reopens it for the
worker.
Also a cfs_update gets triggered as (other) workers may change the
cluster state.

also use the new introduction HA-Env method to clean up after
we forked an LRM worker.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

change include order to register resource plugin correctly

remove ugly import hack

Not required if we register resources from the Env class.

use require to include resources from simulation environment

Because the may not be installed on a normal system.

Move exec_resource_agent from environment classes to LRM

With the changes and preparation work from the previous commits
we can now move the quite important method exec_resource_agent
from the Env classes to the LRM where it get's called.

The main advantage of this is that it now underlies regression
tests and that we do not have two separate methods where it
- does not make sense as agents them self should be virtualized
  not the method executing them
- adds more work as the must (or at least should) be in sync

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

PVE::HA::Config: use import flag to load appropritate resources

Add virtual resources for tests and simulation

Introduce a base class for Virtual Resources with almost all methods
already implemented.
Also add a class for virtual CTs and VMs, with the primary
distinction that CTs may not migrate online.

The Resource are registered in the Hardware class and overwrite
any already registered resources from the same type (e.g. VirtVM
overwrites PVEVM) so that the correct plugins are loaded for
regression tests and the simulator.

This makes the way free for adding(deterministic) 'malicious'
resources, so we can make test where, for example, a service fails
a few times to start or migrate.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Env: add method to get hardware object

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

add 'haenv' parameter to plugin method 'check_running'

This is preparation work and needed when adding virtual resources
for testing/simulation purpose.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Split up resources and move them to own sub folder

Implementing every resource in the base 'Resources' class is a bit
messy, especially if more resource agent get added.

This moves each class to a own Perl module in the new 'Resources'
sub folder.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

LRM: do not release lock on shutdown errors

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

bump version to 1.0-19

remove 'running' from migrate/relocate log message

As relocate is never 'running' and migrate is only 'running
if the resource is a VM this could only generate confusion,
better use an neutral message.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

LRM: release lock also on restart

Wen restarting the LRM (e.g. on a update) we get an new pid and thus
have to wait for our own lock to timeout.
We can (and should) do that as there are no services or all services
are freezed. If they are freezed only our LRM may touch them so we
we can unfreeze them faster with this patch.

The expected log of the restart-lrm test does not change much as the
test system does not need to wait for a timeout.

This let's the LRM start working directly after a restart,
especially usefull on package updates.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

TestHardware: correct shutdown/reboot behaviour of CRM and LRM

Instead of shutting down the LRM and then killing the CRM we now
also make a shutdown request to the CRM, that mirrors the real world
behaviour much better and let's us also test the lock release from
the CRM.

To accomplish this we add new sim_hardware commands for stopping and
starting the CRM.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

release LRM agent lock on graceful shutdown

Release the agent lock when we shutdown the LRM and stopped all
services.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>