[ClusterLabs] Trying to understand dampening (ping)

[martin doc]

________________________________
From: Andrei Borzenkov <arvidjaar at gmail.com>,  Friday, 15 October 2021 4:59 AM
...
> Dampening defines delay before attributes are committed to CIB.
> Private attributes are never ever written into CIB, so dampening
> makes no sense here. Private attributes are managed by attrd
> itself and you see the latest value.

> If you change transient attribute (without -p option) value you
> will see different values reported by

> attrd_updater -n my_ping -Q

> and

> cibadmin -Q -A "//nvpair[@name='my_ping']"

> until dampening timeout expires.

> This applies even to deleting attribute.

Ok, now I understand what the dampen function does.

If I understand this correctly then this probably makes every documented example of using ocf:pacemaker:ping with a colocation statement wrong because the only way to see the effect of dampen is to use a rule that references the value of pingd directly. That or the script for ping has a major flaw with respect to dampen.

That is when I do this:

pcs resource create myPing ocf:pacemaker:ping host_list=192.168.1.1 failure_score=1
pcs resource create database ocf:heartbeat:pgsql
pcs group add pgrp myPing database

PCS will move everything to a new node if there is even 1 ping failure because monitor in ping doesn't look at the dampened value, only the value of the immediate returned value.

The same is true with colocation statements - if a constraint is made with a ping resource without using a rule that references pingd then  the dampen behaviour is ignored completely.

Is the ping'er missing something that does this:

score=`cibadmin -Q -A "//nvpair[@name='ping']" | sed -e 's/.*value="\([^"]*\)".*/\1/'`

before it checks if $score is less than $OCF_RESKEY_failure_score?

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20211014/34de7e1f/attachment.htm>