[Linux-HA] ipfail in V2

[Alan Robertson]

Andrew Beekhof wrote:
> 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.

If you had a field which you update, and their is no delay timer 
running, then you have to create a new timer.  Otherwise, you just leave 
it alone or shorten it.  I wouldn't usually call it extending the timer, 
but the Aussies and Americans have everything in common but language ;-)

If that's not the case you meant, then I really didn't get 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 :-)

This would only be a problem if you have 2 or more clients trying to 
update the same attribute for the same node at the same time.  This 
sounds terminally dumb to me - since there is no read-modify-write 
semantic, nor is there locking...

The limited kind of updates envisioned _for this case_ seem pretty safe 
from this kind of behavior.

>>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.

That might occur _in general_, but node attributes are kind of special 
cases.  Much simpler.  If someone removed the node attribute, then 
setting it should just recreate it, IMHO...


-- 
     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 
Wilberforce