[Linux-HA] ipfail in V2

Alan Robertson alanr at unix.sh
Fri Oct 21 00:04:24 MDT 2005

Andrew Beekhof wrote:
> On 10/20/05, Alan Robertson <alanr at unix.sh> wrote:
>>Andrew Beekhof wrote:
>>>On 10/20/05, Alan Robertson <alanr at unix.sh> wrote:
>>>>Andrew Beekhof wrote:
>>>>>On 10/20/05, Alan Robertson <alanr at unix.sh> wrote:

[big snip]

>>>>>if you are the current winner, you should always update the CIB with
>>>>>your changed stable value (so that the previous step is always correct)
>>>>This is of no help.  It does not provide hysteresis at all.  Averaging
>>>>is NOT delay - and it only works for integers anyway...
>>>i dont recall saying average
>>Mea culpa.
>>Lars said "running average" and you said "rolling history window" - and
>>I mistakenly equated them.
> np. the idea behind my history window was to avoid pudating the CIB
> with N if you were probably going to update it with N+/-1 in some time
> interval.

But, its the notification that needs to be delayed, not the updating, 
I'm afraid.

> one thing that i will say (just between you, me and whoever is still
> paying attention) is that there is a back door in all this.
> I haven't advertised it because frankly its evil.
> So evil that even the CRM doesn't use it anymore.
> There is an option to say: "make this update, but dont tell anyone".
> The update still gets distributed (so consistency is preserved), but
> the CIB clients aren't told it happened.
> The TE is a client of the CIB.
> If the TE doesn't know the change happened, its not going to poke the PE.
> If no-one pokes the PE, nothing gets moved.
> I'll let you fill in the rest.
> In the long term, I think there is no substitute for an ipfail daemon.

Yes.  But, this hysteresis updating would allow it to be very simple 
indeed, and would set a nice simple precedent for other ipfail things.

> Don't think I'm trying to replace that, I'm really not.
> But in the meantime, this combined with some of the things I've
> previously mentioned may be enough for people to "get by" with.
>>But delaying each node separately by the same amount (which is what this
>>will do) doesn't change anything.
> well i was hoping to do more than just delay the updates.  i was
> hoping to aggregate them and thus reduce the number of times we dip
> into the PE.

The hysteresis would in effect aggregate them - from the point of view 
of the PE, like this:
	t1:	node 1 updates (hysteresis timer set for t4)
	t2:	node 2 updates (hysteresis timer unchanged)
	t3:	node 3 updates (hysteresis timer unchanged)
	t4:	hysteresis timer pops - all clients get notified
		of the new CIB.

This aggregates the notification, and reduces the number of times you 
dip into the PE, but doesn't aggregate the CIB updates.

You may think it is evil.  It may _be_ evil.  But, it is really useful ;-)

The question is, after thinking about it, _is_ it really evil?

Could you add a timer to it to notify people in a delayed fashion 
(rather than never notifying them)?  Of course, if you could, then you 
could change that attribute updating command to use it, and the CIB/CRM 
work would be completely done.

Writing the new ipfail and friends would be really easy then.

     Alan Robertson <alanr at unix.sh>

"Openness is the foundation and preservative of friendship...  Let me 
claim from you at all times your undisguised opinions." - William 

More information about the Linux-HA mailing list