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'm not sure how I missed this previously, but this statement is just
not true.
If the only change to the CIB is to "num_updates", then the PE is
never re-invoked.
This has been the case for about as long as I can remember.
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
