On Sat, Oct 22, 2011 at 7:14 AM, Lars Ellenberg <[email protected]> wrote: > On Thu, Oct 20, 2011 at 08:48:36AM -0600, Alan Robertson wrote: >> On 10/20/2011 03:41 AM, Philipp Marek wrote: >> > Hello, >> > >> > when constantly sending new data via attrd the changes are never used. >> > >> > >> > Example: >> > while sleep 1 >> > do attrd_updater -l reboot -d 5 -n rep_chg -U try$SECONDS >> > cibadmin -Ql | grep rep_chg >> > done >> > >> > This always returns the same value - the one that was given with more than >> > 5 >> > seconds delay afterwards, so that the dampen interval wasn't broken by the >> > next change. >> > >> > >> > I've attached two draft patches; one for allowing the _first_ value in a >> > dampen interval to be used (effectively ignoring changes until this value >> > is >> > written), and one for using the _last_ value in the dampen interval (by not >> > changing the dampen timer). [1] >> > >> > >> > *** Note: they are for discussion only! >> > *** I didn't test them, not even for compilation. > >> > What is the correct way to handle multiple updates within the dampen >> > interval? > >> Personally, I'd vote for the last value. I agree with you about this >> being a bug. > > If the attribute is used to check connectivity changes (ping resource > agent), or similar, and we have a "flaky", "flapping" connectivity, > it would be useful to have a "max" or "min" consolidation function > for incoming values during a dampen interval. > > Otherwise, I get + + - + + -|+ + + + > and if the dampen interval just "happened" to expire > where I put the | above, it would have pushed a - to the cib, > where I'd rather kept it at +.
Thats why dampen should typically be a multiple of the monitor interval. > > We likely want to add an option to attrd_updater (and to the ipc > messages it sends to attrd, and to the rest of the chain involved), > which can specify the consolidation function to be used. > > The initial set I suggest would be > generic: > oldest > latest (default?) > for values assumed to be numeric: > max (also a candidate for default behaviour) > min > avg (with a printf like template for rounding, %.2f or similar, > so we could even average "boolean" values) For avg you'd need to specify how many values to remember. > > I suggest this behaviour: > > * If different updates request a different consolidation function, > the last one (within the respective dampen interval) wins. > > * update with the _same_ value: Do not start or modify any timer. > If a timer is pending, still add the value to the list of values to > be processed by the consolidation function (relevant for avg, > possibly not yet listed others). > > * update with a different value: > Start a new timer, unless one is pending already. > Do not restart/modify an already pending timer. > Add to the list of values for the consolidation function. > > * Flush message received: expire timer. See below. > > * Timer expires: > Apply consolidation function to list of values. If list is empty > (probably flush message without pending timer), use current value. > Send that result to the cib. Sounds reasonable, there's no way I'm going to be able to get to implement it any time soon though. If someone else wants to implement it, I think it would be useful to have it be part of a larger rework that ensured atomicity of the updates. I.e. have all nodes send their values to a designated instance which did all the updates. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
