[Pacemaker] attrd waits one second before doing update

[Andrew Beekhof]

On 12/04/2013, at 5:45 PM, Rainer Brestan <rainer.brestan at gmx.net> wrote:

> OK, and where is the difference between 1.1.8 and 1.1.7.

Prior to 1.1.8 the local node flushed its value immediately, which caused the CIB to be updated too soon (compared to the other nodes).
Since the whole point of attrd is to try and have them arrive at the same time, we changed this to be more consistent.

> I am currently testing this on a one node cluster, so attrd wait for the message come back from himself.
> This cant take one second, or is attrd waiting this time anyhow to be sure to get it from all nodes back?

There is no additional delay, the local node flushes its value as soon as the message comes back to itself (and therefor all other nodes too)

> Rainer
>  
> Gesendet: Freitag, 12. April 2013 um 02:03 Uhr
> Von: "Andrew Beekhof" <andrew at beekhof.net>
> An: "The Pacemaker cluster resource manager" <pacemaker at oss.clusterlabs.org>
> Betreff: Re: [Pacemaker] attrd waits one second before doing update
> 
> On 12/04/2013, at 7:17 AM, Rainer Brestan <rainer.brestan at gmx.net> wrote:
> 
> > In pacemaker 1.1.7-6 with corosync 1.4.1-7 update of attributes works almost online.
> > Used with SysInfo resource agent and manual commands like "attrd_updater -U 4 -n test".
> >
> > In the logfile there is one line
> > attrd[...] notice: attrd_trigger_update: Sending flush up to all hosts for: ...
> > and a few milliseconds later
> > attrd[...] notice: attrd_perform_update: Sent update ...
> > with the same content.
> >
> > After upgrade to version 1.1.8-6 there is always nearly exact one second between trigger and perform.
> > 2013-04-11T22:51:55.389+02:00 int2node2 attrd[28370] notice: notice: attrd_trigger_update: Sending flush op to all hosts for: text (81)
> > 2013-04-11T22:51:56.397+02:00 int2node2 attrd[28370] notice: notice: attrd_perform_update: Sent update 5814: text=81
> >
> > And what i found out having several updates running, they have a single queue.
> > All attrd_updater processes are waiting for the next to be finished, so there cant be more than one update per second any more.
> >
> > Has this something to do with
> > attrd: Have single-shot clients wait for an ack before disconnecting
> > stated in the Changelog for 1.1.8 ?
> 
> No, nothing at all.
> 
> >
> > If yes, is it intended to have a single queue ?
> 
> More like unavoidable, since we need to talk to the other nodes and messages between them are ordered.
> 
> > And is this 1 second fixed ?
> > From where does this 1 second come, i dont think that it takes one second to get the ack.
> 
> When the timer expires, attrd sends a cluster message to all nodes (including itself) telling them to update the CIB with their current value.
> The delay comes from waiting for the cluster message we sent to arrive back again before sending our own updates, this helps ensure all the updates arrive in the CIB at almost the same time.
> 
> >
> > This can run into heavy delays (and therefore timeouts) for monitor functions of RA performing attribute updates.
> >
> > Rainer
> > _______________________________________________
> > Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> >
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> > Bugs: http://bugs.clusterlabs.org
> 
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org