build: correct upload target for Jessie

bump version to 1.0-41

always queue service stop if node shuts down

Commit 61ae38eb6fc5ab351fb61f2323776819e20538b7 which ensured that
services get freezed on a node reboot had a side effect where running
services did not get gracefully shutdown on node reboot.
This may lead to data loss as the services then get hard killed, or
they may even prevent a node reboot because a storage cannot get
unmounted as a service still access it.

This commits addresses this issue but does not changes behavior of
the freeze logic for now, but we should evaluate if a freeze makes
really sense here or at least make it configurable.

The changed regression test is a result of the fact that we did not
adapt the correct behavior for the is_node_shutdown command in the
problematic commit. The simulation envrionment returned true
everytime a node shutdown (reboot and poweroff) and the real world
environment just returned true if a poweroff happened but not on a
reboot.

Now the simulation acts the same way as the real environment.
Further I moved the simulation implemenentation to the base class so
that both simulator and regression test system behave the same.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
(cherry picked from commit f65f41b9d8fcdb1517f2089c9f1b5abb4fbaedc7)

Resource/API: abort early if resource in error state

If a service is in error state the single state change command that
can make sense is setting the disabled request state.
Thus abort on all other commands early to enhance user experience.

buildsys: update make upload target

buildsys: don't pull qemu/lxc during doc-generation

buildsys: make job safety

buildsys: drop libsystemd-daemon-dev build dep

We don't actually need it and it and on stretch
libsystemd-dev (which we still depend on) replaces it.

bump version to 1.0-40

sim: allow adding service on runtime

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

sim: factor out service gui entry addition

Will be used to allow adding services to the simulator on runtime in
a future patch.

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

sim: allow deleting service via GUI

Add a delete button to each service entry row. This allows deleting a
service on runtime.

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

sim: allow new service request states over gui

Change the old enabled/disabled GTK "Switch" element to a ComboBox
one and add all possible service states, so we can simulate the real
world behaviour with its new states better.

As we do not need to map a the boolean swicth value to our states
anymore, we may drop the set_setvice_state method from the RTHardware
class and use the one from the Hardware base class instead.

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

factor out and unify sim_hardware_cmd

Most things done by sim_hardware_cmd are already abstracted and
available in both, the TestHardware and the RTHardware class.

Abstract out the CRM and LRM control to allow the unification of both
classes sim_hardware_cmd.

As in the last year mostly the regression test systems TestHardware
class saw new features use it as base.

We return now the current status out of the locked context, this
allows to update the simulators GUI out of the locked context.

This changes increases the power of the HA Simulator, but the new
possible actions must be still implemented in its GUI. This will be
done in future patches.

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

sim: allocate HA Env only once per service and node

Do not allocate the HA Environment every time we fork a new CRM or
LRM, but once at the start of the Simulator for all nodes.
This can be done as the Env does not saves any state and thus can be
reused, we use this also in the TestHardware class.
Making the behavior of both Hardware classes more similar allows us
to refactor out some common code in following commits.

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

Status: factor out new service state calculation

Factor out the new "fast feedback for user" service state calculation
and use it also in the HA Simulator to provide the same feedback as
in the real world.

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

sim: show current master node more prominent

just upercasing the node status if it is the current master is not
really intuitive

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

sim: improve canceling the migrate dialog

We could only cancel the migrate dialog by pressing ESC or - if the
used window manager supports it - by pressing the windows "X" button
in the window border.
Pressing ESC caused a warning because the result of the domain was
now a string containing the signal names, as we checked for an
integer to see if the "Ok" button was pressed perl warned us about:
 > Argument "closed" isn't numeric in int at ...

Improve this by adding a cancel button and by switching the button
return values from integer to strings, which can be compared in a
more general way.

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

sim: set migrate dialog transient to parent

This allows window managers to e.g. keep the dialog on top of the
main window, or center the dialog over the main window.
Fixes also a warning that the dialog had no transient parent

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

sim: use JSON instead of Dumper for manager status view

This gives a little cleaner output, we can omit the Data::Dumper use
completely and need not 'sort dumper key' hack to keep the output
stable

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

ensure test/sim.pl always use the currently developed code

sim.pl suggested to be a perl script, but was a bash script which
called ../pve-ha-simulator
It set the include directory to '..' as its intended to use the
currently developed code, not the pve-ha-simulator installed on the
system.
This did not work correctly as pve-ha-simulator has a
use lib '/global/path/to/HA/Simulator'
directive.

Create a small perl script which runs the RTHardware.

Changes which differ from the pve-ha-simulator script include that we
fall back to the 'simtest' directory if none is given.
Also the 'batch' option does not exists here, use the ha-tester
script if you want this behavior.

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

bump version to 1.0-39

add setup_environment hook to CLIHandler class

And use run_cli_handler instead of depreciated run_cli.

ha-simulator: fix typo s/Mode/Node/

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

is_node_shutdown: check for correct systemd targets

shutdown.target is active every time when the node shuts down, be it
reboot, poweroff, halt or kexec.
As we want to return true only when the node powers down without a
restart afterwards this was wrong.
Match only poweroff.target and halt.target, those two systemd targets
which cause a node shutdown without a reboot.

Enhance also the regular expression so that we do not falsely match
when a target includes poweroff.target in its name, e.g.
not-a-poweroff.target

Also pass the 'full' flag to systemctl to ensure that target name do
not get ellipsized or cut off.

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

use POSIX::_exit

we do not want to use the parents perl code exit path here but exit
directly

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

Simulator: fix scrolling to end of cluster log view

As the cursor may be set by the user, even if invisible, scrolling to
its position to reach the end of the TextView is potentially flawed.
Connect a signal on the 'size-allocate' event of the TextView element
instead. This event gets triggered on all size changes of the
TextViews.
In the call back use the ScrolledWindow methods to correctly scroll
to the end of its child (the TextView).

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

Simulator: do not use cursor position to insert log

While the cursor is set invisible it can be still set by clicking
somewhere in the log window. As we uset insert_at_cursor() to append
text, asuming that the cursor is always at the end, this results in
an erroneous behavior where new log text get inserted at arbitrary
positions.
Use get_end_iter() to get the real end of the text buffer instead.

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

bump version to 1.0-38, update manual page

bump version to 1.0-37

HA::Status: provide better/faster feedback - show disabled state

Manager.pm: store flag to indicate successful start

Produce better feedback.

ha status: include common service attributes

We can use this to simplify the GUI.

HA::Status: provide better/faster feedback to users

Groups.pm: add verbose_description for 'restricted'

Resources.pm: use verbose_description for state.

Avoid dumplication of same text in the manual page.

pve-ha-group-node-list: add verbose_description

service_check_ha_state: improve backward compatibility

ha-manager: remove 'enabled' and 'disabled' commands

This should be done with:
ha-manager set SID --state STATE

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

rename request state 'enabled' to 'started'

with the new 'stopped' state there was a possible confusion what each
state could do. Rename enabled to started to started to address this.

Enabled can still be used for backward compatibility and will be
removed on the next major release.

The TestHardware does not recognizes the "service enable" command
anymore, the regression test which made use of it were ported to
"service started" command.

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

introduce new resource start 'started' (replaces enabled).

We want to replace 'enabled' with 'started'. Functionality follows
in the next patches.

get_pve_lock: fix retry_timeout

get_pve_lock: only call cfs lock update request withing retry window

Because it is guaranteed to fail outside this time frame. This is
more or less an optimization to avoid unnecessary cluster traffic.

get_pve_lock: avoid unnecessary test if $last_lock_time is zero

This is just a cleanup.

get_pve_lock: always send a lock update request

add regression test for 'stopped' state

Test that:
* stopped service will not start
* stopped service will be recovered
* stopped service can me relocated

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

bump version to 1.0-36

skip transition to 'started' state if we won't stay in it

If we add a resource wth disabled or stopped state we went through
the started state before changing directly to the request_stop state.

Skip the started state entirely and go direct to the request_stop
state.

This is a small behavioral change, as we never wrote in the
manager_status that we were in the started state but changed directly
to request_stop, so the LRM cannot be affected by this change.

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

implement 'stopped' state

In stopped state we do not start a service but we recover it on
fencing.
This can be practical for templates or cold standby guests.

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

Resources: add 'stopped' state

without any functionality for now.

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

ha-manager: remove obsolet pod content

we generate man pages now from pve-docs package so this is obsolete

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

Fix #1189: correct spelling in fence mail

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

API/Status: avoid using HA Environment

using the environment here is just overhead as it calls functions we
could call also directly here and this code gets only called from the
PVE2 environment and not the test/simulator environment.

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

factor out resource config check and default set code

Factor the code which does basic checks and sets default settings
out from the PVE2 environment class to the Config class as
read_and_check_resources_config method.

We can reuse this in the HA API status call.

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

bump version to 1.0-35

Sim/Hardware: not warn if a not locked gets unlocked

This adds a warning without value to the regression test stderr
output, does not affects the test itself but can be annoying.

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

change service state to error if no recovery node is available

else we will try again endlessly if the service has no other
possible node where it can run, e.g. if its restricted.

This avoids various problems, especially if a service is configured
to just one node we could never get the service out of the fence
state again without manually hacking the manager status.

Add a regression test for this.

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

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/