________________________________ From: Andrei Borzenkov <arvidj...@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
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
