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: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
