[ClusterLabs] Question about ping nodes

[Ken Gaillot]

On Sun, 2021-04-18 at 17:31 +0300, Andrei Borzenkov wrote:
> On 18.04.2021 08:41, Andrei Borzenkov wrote:
> > On 17.04.2021 22:41, Piotr Kandziora wrote:
> > > Hi,
> > > 
> > > Hope some guru will advise here ;)
> > > 
> > > I've got two nodes cluster with some resource placement dependent
> > > on ping
> > > node visibility (
> > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-moving_resources_due_to_connectivity_changes-haar
> > > ).
> > > 
> > > Is it possible to do nothing with these resources when both nodes
> > > do not
> > > have access to the ping node?
> > > 
> > > Currently, when the ping node is unavailable (node itself becomes
> > > unavailable) both nodes stop the resources.
> > > 
> > 
> > Just use any negative score higher than -INFINITY in location
> > constraint.
> > 
> 
> No, it does not work. I was mislead by documentation (5.2.1 location
> properties):

Actually your initial interpretation was correct. Using a non-infinite
negative score for the location constraint should work as expected --
the resource can still run there if there's no better place.

I'm not sure why you didn't see that in your test, maybe some other
factor prevented it from running?

BTW another solution to the initial problem would be to use multiple
IPs in the ping agent. It would be less likely for all of them to be
down at the same time without a network issue.

> 
> score:
> 
> Negative values indicate the resource(s) should avoid this node (a
> value
> of -INFINITY changes "should" to "must").
> 
> I interpreted "should" as "pacemaker will normally avoid this node
> but
> still may chose it if nothing better is possible". It is not what
> happens. Apparently negative score completely prevents assigning
> resource to this node, and "should" here probably means "it is still
> possible that final score may become positive".
> 
> As it is not possible to refer to attributes of multiple nodes in a
> rule, you would need something that combines current pingd status for
> individual nodes and makes it available. Logical place is
> ocf:pacemaker:ping resource agent itself.
-- 
Ken Gaillot <kgaillot at redhat.com>