Andrew Beekhof wrote: > > On Apr 5, 2007, at 4:48 PM, Alan Robertson wrote: > >> Alan Robertson wrote: >>> Lars Marowsky-Bree wrote: >>>> On 2007-04-04T11:41:44, Doug Knight <[EMAIL PROTECTED]> wrote: >>>> >>>>> The key word in my question was "thinks". It would be useful to the RA >>>>> if it could know what state the CRM thought it was in, so in case >>>>> the RA >>>>> determines on its own that its already in that state, it doesn't >>>>> have to >>>>> do anything. But, if the RA finds that the CRM thinks its in a >>>>> different >>>>> state, then the RA could set the CRM straight by calling the >>>>> crm_master >>>>> with the appropriate value. Make sense? >>>> No. The state the resource is in is not set via crm_master, but using >>>> the exit code of the monitor operation. >>>> >>>> You should only call crm_master when you wish to change the >>>> _preference_ >>>> for master-state. >>> >>> But, I think you can use crm_master to retrieve your current preference, >>> and thereby eliminate unnecessary CIB updates. >>> >>> Or maybe crm_master should do that filtering on its own?? >> >> Attached is a straightforward patch to crm_attribute.c which I believe >> does this... >> >> It also eliminates certain other "do-nothing" attribute changes - >> because this code is shared by a few different commands. >> >> I recognize that this is slightly less efficient for those cases where >> the attribute is actually going to be changed, but it is _vastly_ more >> efficient for those cases where the current value is correct - because >> it eliminates triggering a computation cycle of the policy engine. > > I would prefer to fix this in the CIB (by not always upping the version > number unless something actually changed) > This has been a long-standing issue which we know we need to work on - > along with not syncing the status section. > > And until then, why not just use -G to grab the current value and > compare it with what you would have set? thats 2 lines of shell script...
In every shell script that does it... And, educating everyone that might want to do it, even if we had well-organized docs... IMHO, this is unlikely to happen in practice beyond one or two people. I'd rather have a workaround in _our_ code than our customers' code. We can always remove it later, but we can't do that for others. The proposed patch is clean and straightforward, and a lot simpler than fixing this problem more generally in the CIB. It's not like this patch precludes fixing it in the CIB, nor harms the CIB in any way that I can see. I'm all for getting it fixed in the CIB. If it were already fixed, I wouldn't have suggested this. I also know you're very busy. Do you have a planned availability date for the CIB fix? -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/