Mailing List Archive

On 9 Sep 2014, at 4:11 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

>>>> Andrew Beekhof <andrew@beekhof.net> schrieb am 09.09.2014 um 00:25 in Nachricht
> <C19365B9-B626-471E-A92A-001950D01277@beekhof.net>:
>
>> On 8 Sep 2014, at 5:19 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
>> wrote:
>>
>>> Hi!
>>>
>>> I remember having asked this before, but I'l still missing a good
>> explanation:
>>>
>>> What are the precise semantics of "dampening" (attrd_updater -d)?
>>>
>>> The manual page just says:
>>> -d, --delay=value
>>> The time to wait (dampening) in seconds further changes occur
>>>
>>> Who is waiting?
>>
>> attrd before it updates the cib
>
> So the RA sees an extra delay of -d seconds?

No. attrd does the waiting, not attrd_updater

>
>>
>>> What changes?
>>
>> other processes or nodes calling attrd_updater
>
> So it means that if you call "attr_updater -d X" and then "attr_updater -d Y" the second update will be delayed until at least X seconds since the first update passed?

No. It means wait X seconds for another update (locally or on another node) before writing the value to the CIB.
If another update does arrive, reset the clock and wait another X seconds. Repeat.

Usually only the -d from the first call to attrd_updater has any affect.
Subsequent calls re-use the -d value from the first.

> If a third "attr_updater -d Z" is called, will the system ensure that at least X + Y seconds passed since the first update before appying the third update?

No.

>
> If the delay is not over, does the next update wait (as I guessed), or is the next update simply ignored?
>
>>
>>> Please explain!
>
> As you see, there are too many questions that are still unanswered.
>
>>> (pacemaker-1.1.10-0.15.25 of SLES11 SP3)
>>>
>>> Regards,
>>> Ulrich
>
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

On Tue, Sep 09, 2014 at 05:10:33PM +1000, Andrew Beekhof wrote:
>
> On 9 Sep 2014, at 4:11 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>
> >>>> Andrew Beekhof <andrew@beekhof.net> schrieb am 09.09.2014 um 00:25 in Nachricht
> > <C19365B9-B626-471E-A92A-001950D01277@beekhof.net>:
> >
> >> On 8 Sep 2014, at 5:19 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
> >> wrote:
> >>
> >>> Hi!
> >>>
> >>> I remember having asked this before, but I'l still missing a good
> >> explanation:
> >>>
> >>> What are the precise semantics of "dampening" (attrd_updater -d)?
> >>>
> >>> The manual page just says:
> >>> -d, --delay=value
> >>> The time to wait (dampening) in seconds further changes occur
> >>>
> >>> Who is waiting?
> >>
> >> attrd before it updates the cib
> >
> > So the RA sees an extra delay of -d seconds?
>
> No. attrd does the waiting, not attrd_updater
>
> >
> >>
> >>> What changes?
> >>
> >> other processes or nodes calling attrd_updater
> >
> > So it means that if you call "attr_updater -d X" and then "attr_updater -d Y" the second update will be delayed until at least X seconds since the first update passed?
>
> No. It means wait X seconds for another update (locally or on another node) before writing the value to the CIB.
> If another update does arrive, reset the clock and wait another X seconds. Repeat.
>
> Usually only the -d from the first call to attrd_updater has any affect.
> Subsequent calls re-use the -d value from the first.
>
> > If a third "attr_updater -d Z" is called, will the system ensure that at least X + Y seconds passed since the first update before appying the third update?
>
> No.

Some of this has been discussed before:
http://www.gossamer-threads.com/lists/linuxha/dev/75740?do=post_view_threaded#75740

Basic idea of "attr_updater -d delay" is in fact
"wait for the dust to settle",
especially for attribute based constraints,
as used with the ping RA.

Current behaviour (afai understand it):

If a new update comes in while a previous update is still "pending",
the timer of the new update is *ignored*,
the new value is queued instead, and
the original timer is restarted.

(UNLESS the "new" value is the same as the currently pending value.
Otherwise values would never reach the cib if the update interval
is shorter than the dampening interval.)

Value is put into the cib only if the original timer actually expires,
or attrd "flushes out" all current values for some other reason.

-----

Problem:
for "flapping" or otherwise continually changing values,
new values won't make it into the cib for "a long time".

Workaround:
use a dampening interval shorter than the update interval.

Problem with that workaround: you may still hit the same undesired
situations you could reach with immediately updating the values, you
did not wait for "the dust to settle".


Proposal:

add a "update deadline" along with the dampening, which would normally
be sufficiently larger, and count from the original update (this timer
would not be restarted).

Optionally feed all updates into an aggregate function.
Default aggregate function may be "latest value".

Once the "update deadline" is reached,
(submitted values still changing; flapping? ...)
write out the current "aggregate" value anyways.

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 9 Sep 2014, at 11:12 pm, Lars Ellenberg <Lars.Ellenberg@linbit.com> wrote:

> On Tue, Sep 09, 2014 at 05:10:33PM +1000, Andrew Beekhof wrote:
>>
>> On 9 Sep 2014, at 4:11 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>
>>>>>> Andrew Beekhof <andrew@beekhof.net> schrieb am 09.09.2014 um 00:25 in Nachricht
>>> <C19365B9-B626-471E-A92A-001950D01277@beekhof.net>:
>>>
>>>> On 8 Sep 2014, at 5:19 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
>>>> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> I remember having asked this before, but I'l still missing a good
>>>> explanation:
>>>>>
>>>>> What are the precise semantics of "dampening" (attrd_updater -d)?
>>>>>
>>>>> The manual page just says:
>>>>> -d, --delay=value
>>>>> The time to wait (dampening) in seconds further changes occur
>>>>>
>>>>> Who is waiting?
>>>>
>>>> attrd before it updates the cib
>>>
>>> So the RA sees an extra delay of -d seconds?
>>
>> No. attrd does the waiting, not attrd_updater
>>
>>>
>>>>
>>>>> What changes?
>>>>
>>>> other processes or nodes calling attrd_updater
>>>
>>> So it means that if you call "attr_updater -d X" and then "attr_updater -d Y" the second update will be delayed until at least X seconds since the first update passed?
>>
>> No. It means wait X seconds for another update (locally or on another node) before writing the value to the CIB.
>> If another update does arrive, reset the clock and wait another X seconds. Repeat.
>>
>> Usually only the -d from the first call to attrd_updater has any affect.
>> Subsequent calls re-use the -d value from the first.
>>
>>> If a third "attr_updater -d Z" is called, will the system ensure that at least X + Y seconds passed since the first update before appying the third update?
>>
>> No.
>
> Some of this has been discussed before:
> http://www.gossamer-threads.com/lists/linuxha/dev/75740?do=post_view_threaded#75740
>
> Basic idea of "attr_updater -d delay" is in fact
> "wait for the dust to settle",
> especially for attribute based constraints,
> as used with the ping RA.
>
> Current behaviour (afai understand it):
>
> If a new update comes in while a previous update is still "pending",
> the timer of the new update is *ignored*,
> the new value is queued instead, and
> the original timer is restarted.

I think thats what I wrote but longer :)

>
> (UNLESS the "new" value is the same as the currently pending value.
> Otherwise values would never reach the cib if the update interval
> is shorter than the dampening interval.)
>
> Value is put into the cib only if the original timer actually expires,
> or attrd "flushes out" all current values for some other reason.
>
> -----
>
> Problem:
> for "flapping" or otherwise continually changing values,
> new values won't make it into the cib for "a long time".

Do we have many attributes like that?

>
> Workaround:
> use a dampening interval shorter than the update interval.
>
> Problem with that workaround: you may still hit the same undesired
> situations you could reach with immediately updating the values, you
> did not wait for "the dust to settle".
>
>
> Proposal:
>
> add a "update deadline" along with the dampening, which would normally
> be sufficiently larger, and count from the original update (this timer
> would not be restarted).
>
> Optionally feed all updates into an aggregate function.
> Default aggregate function may be "latest value".
>
> Once the "update deadline" is reached,
> (submitted values still changing; flapping? ...)
> write out the current "aggregate" value anyways.
>
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

On Wed, Sep 10, 2014 at 03:00:15PM +1000, Andrew Beekhof wrote:
> >>>>> What are the precise semantics of "dampening" (attrd_updater -d)?

> > Basic idea of "attr_updater -d delay" is in fact
> > "wait for the dust to settle",
> > especially for attribute based constraints,
> > as used with the ping RA.
> >
> > Current behaviour (afai understand it):
> >
> > If a new update comes in while a previous update is still "pending",
> > the timer of the new update is *ignored*,
> > the new value is queued instead, and
> > the original timer is restarted.
>
> I think thats what I wrote but longer :)

Absolutely :)

> > (UNLESS the "new" value is the same as the currently pending value.
> > Otherwise values would never reach the cib if the update interval
> > is shorter than the dampening interval.)
> >
> > Value is put into the cib only if the original timer actually expires,
> > or attrd "flushes out" all current values for some other reason.
> >
> > -----
> >
> > Problem:
> > for "flapping" or otherwise continually changing values,
> > new values won't make it into the cib for "a long time".
>
> Do we have many attributes like that?

I've seen it once for ping attributes with a dieing switch.
I guess that qualifies as "Not around here.".

> > Workaround:
> > use a dampening interval shorter than the update interval.
> >
> > Problem with that workaround: you may still hit the same undesired
> > situations you could reach with immediately updating the values, you
> > did not wait for "the dust to settle".
> >
> >
> > Proposal:
> >
> > add a "update deadline" along with the dampening, which would normally
> > be sufficiently larger, and count from the original update (this timer
> > would not be restarted).
> >
> > Optionally feed all updates into an aggregate function.
> > Default aggregate function may be "latest value".
> >
> > Once the "update deadline" is reached,
> > (submitted values still changing; flapping? ...)
> > write out the current "aggregate" value anyways.


--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 10 Sep 2014, at 6:43 pm, Lars Ellenberg <Lars.Ellenberg@linbit.com> wrote:

> On Wed, Sep 10, 2014 at 03:00:15PM +1000, Andrew Beekhof wrote:
>>>>>>> What are the precise semantics of "dampening" (attrd_updater -d)?
>
>>> Basic idea of "attr_updater -d delay" is in fact
>>> "wait for the dust to settle",
>>> especially for attribute based constraints,
>>> as used with the ping RA.
>>>
>>> Current behaviour (afai understand it):
>>>
>>> If a new update comes in while a previous update is still "pending",
>>> the timer of the new update is *ignored*,
>>> the new value is queued instead, and
>>> the original timer is restarted.
>>
>> I think thats what I wrote but longer :)
>
> Absolutely :)
>
>>> (UNLESS the "new" value is the same as the currently pending value.
>>> Otherwise values would never reach the cib if the update interval
>>> is shorter than the dampening interval.)
>>>
>>> Value is put into the cib only if the original timer actually expires,
>>> or attrd "flushes out" all current values for some other reason.
>>>
>>> -----
>>>
>>> Problem:
>>> for "flapping" or otherwise continually changing values,
>>> new values won't make it into the cib for "a long time".
>>
>> Do we have many attributes like that?
>
> I've seen it once for ping attributes with a dieing switch.
> I guess that qualifies as "Not around here.".

That would surely converge on 0 though right?

>
>>> Workaround:
>>> use a dampening interval shorter than the update interval.
>>>
>>> Problem with that workaround: you may still hit the same undesired
>>> situations you could reach with immediately updating the values, you
>>> did not wait for "the dust to settle".
>>>
>>>
>>> Proposal:
>>>
>>> add a "update deadline" along with the dampening, which would normally
>>> be sufficiently larger, and count from the original update (this timer
>>> would not be restarted).
>>>
>>> Optionally feed all updates into an aggregate function.
>>> Default aggregate function may be "latest value".
>>>
>>> Once the "update deadline" is reached,
>>> (submitted values still changing; flapping? ...)
>>> write out the current "aggregate" value anyways.
>
>
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems