On 2011-07-27 03:46, Andrew Beekhof wrote: > On Fri, Jul 1, 2011 at 4:59 PM, Andrew Beekhof <and...@beekhof.net> wrote: >> Hmm. Interesting. I will investigate. > > This is an unfortunate side-effect of my history compression patch. > > Since we only store the last successful and last failed operation, we > don't have the md5 of the start operation around to check when a > resource's definition is changed. > > Solutions appear to be either: > a) give up the space savings and revert the history compression patch > b) always restart a resource if a non-matching md5 is detected - even > if the operation was a recurring monitor > > I'd favor b) along with dropping the per-operation parameters. > The only valid use-case I've heard for those is setting OCF_LEVEL or > depth or whatever it was called - and I think we're in basic agreement > that we need a better solution for that anyway.
We are, and you know my opinion that OCF_CHECK_LEVEL is hideous
(although lmb, for one, seems to disagree). But dropping it now does
clearly count as a regression and I'd really hate to see that happen unless
a) there is a replacement method for tuning the thoroughness of checking
the resource state during monitor, _and_
b) there is an automated or semi-automated ("cibadmin --upgrade"?) means
of transitioning off OCF_CHECK_LEVEL and replacing it with its successor
feature.
Cheers,
Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
