[Linux-HA] ipfail in V2
alanr at unix.sh
Mon Oct 24 12:35:29 MDT 2005
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:
>>>>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.
>>>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
> 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
More information about the Linux-HA