[Linux-HA] ipfail in V2

Andrew Beekhof beekhof at gmail.com
Fri Oct 21 11:07:45 MDT 2005

On 10/21/05, Alan Robertson <alanr at unix.sh> wrote:
> Andrew Beekhof wrote:
> > On 10/21/05, Alan Robertson <alanr at unix.sh> wrote:
> >
> > [snip]
> [more-snip]
> >>Is this a one-shot timer?  What happens when you get conflicting
> >>"repokes"?  Does the last one win?  That might be OK - at least for
> >>events with similar hysteresis intervals.
> >
> >
> > the repoke is controlled by the DC.
> > it is started when the DC enters the idle state and cancelled if it
> > ever moves out of it.
> > so there is never a conflict - because there is only 1 timer and only
> > 1 node running it.
> >
> > what you're thinking of is a timer running in the CIB.
> Yes.
> > you'd need to indicate somehow that this change should start/extend a timer.
> Almost.  Start or shorten.  Never extend (AFAIK).

After re-updating a field I assume one would need to start the timer
again - ie. extend it.

> The algorithm is this:
>         Is there a delayed notification timer running?
>           If yes, then see how much time is left on it.
>           If the current update is accompanied by a timer and it is
>                 shorter than the remaining time on that timer, then
>                         Cancel the current      delayed notification
>                         timeout and start a new timer with
>                         the timeout which came with the update.
>         If no timer running, then
>                 start a new timer with the value which came with the
>                         update (if any)
> The idea would be that the command for updating the attribute value
> would have a flag for a delayed notification value.
>         crm_attribute -d -n node --set --attribute foo --value bar
>                 (or whatever it is)
> > you'd also need to keep track of which updates have been sent out
> > you'll start confusing clients because the order will be all messed up
> I don't see this as an issue.  The order in which they were updated is
> irrelevant.  They would all appear to the clients to be updated
> simultaneously - which would be perfect.  Or possibly, I misunderstood
> you here.

I mean that changes 1,2,3 and 4 will not always come out in that order
if 2 had to be delayed.
Which is a problem if 3 or 4 also change some of the same data.

Think of it like a series of patches.

I have envisioned clients that would subscribe to changes to keep an
updated view of the CIB as it changed rather than having to query the
CIB all the time.

Messing with notification orders would really mess with that - as does
the super-double-secret-option - but I've already said that the option
is evil and this is part of the reason why I dont use it :-)

> The idea is that you set the delayed notification value to the "settling
> time" for the events which change the value of this attribute.  It's
> kind of like debouncing a switch in software (except in this case it's
> at an even higher level - for the whole cluster).
> > you could even have a situation where the update doesnt even exit
> > anymore because the whole CIB was replaced in the meantime.
> Help me with this one please.  I don't follow this.

You update a field
We start a timer
Something happens which replaces that entire portion of the CIB (this
does happen)

Does the timer still matter?  Who does it relate to? Chances are the
diff wont make sense... etc etc.

More information about the Linux-HA mailing list