but 0 is a valid value - and possibly the most likely one to be set and that strcmp looks wrong to me
i'll apply a modified version of this, but i don't want to get too hung up trying to detect every possible value a hostile admin could throw at the cluster (especially when they can just as easily use cibadmin to achieve the same result). for 1.0 we'll be using relax-NG schemas (instead of DTDs) for validation which will allow us to catch more things like this centrally (on the server) and reject them (and defining what is a valid 'score' is one thing I've already done :-). On Fri, May 16, 2008 at 10:45 AM, Junko IKEDA <[EMAIL PROTECTED]> wrote: > Hi, > > Using Pacemaker stable-0.6, the following operation works well. > > # crm_failcount -r <resource-id> -U <nodename> -v INFINITY > fail-count would be increased to 10000. should be higher than that, INFINITY is 1,000,000 > > This one would fail, > # crm_failcount -r <resource-id> -U <nodename> -v ERROR > > fail-count wouldn't be changed. > But crm_failcount command updates CIB. > > cibadmin -Q sais; > # cibadmin -Q | grep fail-count > <nvpair id="status-db8f2da4-a7fb-40bf-bf14-befe4af11db7-fail-count-dummy" > name="fail-count-dummy" value="ERROR"/> > > It would be convenient if crm_faicount can ignore some string value given by > -v option other than "INFINITY". > See atached. > > Best Regards, > Junko Ikeda > > NTT DATA INTELLILINK CORPORATION > > > _______________________________________________ > Pacemaker mailing list > [email protected] > http://list.clusterlabs.org/mailman/listinfo/pacemaker > > _______________________________________________ Pacemaker mailing list [email protected] http://list.clusterlabs.org/mailman/listinfo/pacemaker
