On Wed, Jul 27, 2011 at 6:12 PM, Florian Haas <florian.h...@linbit.com> wrote: > 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).
His disagreement (IIUC) is with changing it in the RA API - not how its exposed to users in the config. > 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_ That would be the part about promoting it to the 'op' level albeit with a different name (it would still appear as OCF_CHECK_LEVEL in the RA's environment). > b) there is an automated or semi-automated ("cibadmin --upgrade"?) means > of transitioning off OCF_CHECK_LEVEL and replacing it with its successor > feature. Thats what our xslt's do. In any case, the dropping of per-op params is not a pre-req for the "restart the resource on any op change" part. That OCF_CHECK_LEVEL is the only param that is normally set this way just makes option b) palatable. _______________________________________________ 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