[Pacemaker] crm_resource -L not trustable right after restart

Brian J. Murrell (brian) brian at interlinx.bc.ca
Wed Jan 15 21:13:56 EST 2014

On Thu, 2014-01-16 at 08:35 +1100, Andrew Beekhof wrote:
> I know, I was giving you another example of when the cib is not completely up-to-date with reality.

Yeah, I understood that.  I was just countering with why that example is
actually more acceptable.

> It may very well be partially started.


> Its almost certainly not stopped which is what is being reported.

Right.  But until it is completely started (and ready to do whatever
it's supposed to do), it might as well be considered stopped.  If you
have to make a binary state out of stopped, starting, started, I think
most people will agree that the states are stopped and starting and
stopped is anything < starting since most things are not useful until
they are fully started.

> You're not using the output to decide whether to perform some logic?

Nope.  Just reporting the state.  But that's difficult when you have two
participants making positive assertions about state when one is not
really in a position to do so.

> Because crm_mon is the more usual command to run right after startup

The problem with crm_mon is that it doesn't tell you where a resource is

>  (which would give you enough context to know things are still syncing).

That's interesting.  Would polling crm_mon be more efficient than
polling the remote CIB with cibadmin -Q?

> DC election happens at the crmd.

So would it be fair to say then that I should not trust the local CIB
until DC election has finished or could there be latency between that
completing and the CIB being refreshed?

If DC election completion is accurate, what's the best way to determine
that has completed?


More information about the Pacemaker mailing list