Workaround for Pacemaker is to delete the delay:

pcs resource update $FENCING_RESOURCE_NAME delay=

(In reply to Ken Gaillot from comment #1)
> Workaround for Pacemaker is to delete the delay:
> 
> pcs resource update $FENCING_RESOURCE_NAME delay=

This requires a full cluster stop and start to take effect, but that may be a Pacemaker bug.

I pushed a fix for this:

https://github.com/ClusterLabs/fence-virt/commit/d4cd306cb464c12b9d35b062e3de1657c83ef4e0

A fix for a typo (it was checking timeout instead of delay) caused the change in behavior.

Well, this is not correct, either.

My assumption back then with
https://github.com/ClusterLabs/fence-virt/pull/4
(and consequently
https://bugzilla.redhat.com/1204873#fix--delay--parameter-checking)
was "ok, let's keep atoi in place, there's a precedence afterall,
but at least cover all the misguided values with excluding zero
altogether".

Old stack/fenced/libfence seems not to be ever passing values other
than configured, and it's questionable if explicit zero should be
ever accepted (if you want a delay, it's implied it's nonzero[*]).

This questionability is the same for pacemaker, IMHO.

If something good is to be done about the fence-virt codebase,
it should at least move on from very unsuitable "atoi" legacy.
Otherwise it's like changing strings on a neck-broken guitar.


[*] It would be oh-so-nice if the range of declarable data types
followed data types from XML Schema, which would be win also at
derived RelaxNG schemas' level, so one could define this
as positiveInteger
(https://www.w3.org/TR/xmlschema-2/#app-fundamental-facets)

(In reply to Jan Pokorný from comment #5)
> Well, this is not correct, either.
> 
> My assumption back then with
> https://github.com/ClusterLabs/fence-virt/pull/4
> (and consequently
> https://bugzilla.redhat.com/1204873#fix--delay--parameter-checking)
> was "ok, let's keep atoi in place, there's a precedence afterall,
> but at least cover all the misguided values with excluding zero
> altogether".
> 
> Old stack/fenced/libfence seems not to be ever passing values other
> than configured, and it's questionable if explicit zero should be
> ever accepted (if you want a delay, it's implied it's nonzero[*]).

I think an explicit 0 should definitely be accepted:
* 0 is semantically valid (delay is logically nonnegative, not positive)
* Users may have custom front-end scripts that take some values and do cluster config (which happens to be how I ran into the bug).
* It is contrary to expectations that a parameter's default value is illegal.

> This questionability is the same for pacemaker, IMHO.
> 
> If something good is to be done about the fence-virt codebase,
> it should at least move on from very unsuitable "atoi" legacy.
> Otherwise it's like changing strings on a neck-broken guitar.
> 
> 
> [*] It would be oh-so-nice if the range of declarable data types
> followed data types from XML Schema, which would be win also at
> derived RelaxNG schemas' level, so one could define this
> as positiveInteger
> (https://www.w3.org/TR/xmlschema-2/#app-fundamental-facets)

Yes, I agree 0 should be accepted, but it should use strtol or similar instead. I only kept the atoi to make the smallest change possible to restore the old behavior. I can go through the codebase to make these checks more robust throughout the codebase.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2089