[Pacemaker] racing crm commands... last write wins?

[Bob Haxo]

Regarding the replace triggering a DC election ... which is causing
issues with scripted installs ... how do I determine which crm commands
will NOT trigger this election?  I need a way of avoiding this election
while installing.

I'm finding that when repeating the scripted install with the same
commands, sometimes the DC election gets triggered and sometimes it does
not.  With the DC election, these messages get logged, followed by the
whole xml version of the configuration.

Call cib_replace failed (-62): Timer expired
ERROR: 55: could not replace cib
INFO: 55: offending xml: <configuration>

Any suggestions for avoiding replacing rather than incrementally
modifying the configuration?

Thanks,
Bob Haxo
SGI



On Mon, 2013-03-04 at 17:25 +0100, Lars Marowsky-Bree wrote:
> On 2013-03-04T17:14:28, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> 
> > > Thought so at the time, yes. And I do think it cleaned up a few things,
> > > we just need to improve it. The full CIB replace also seems to trigger
> > > an election ...
> > I think that used to happen in Heartbeat clusters but got fixed
> > in the meantime, the details are a bit foggy.
> 
> No, if you look at the current logs on the DC, you'll also see this
> happening. I think it's the replace of the node section that triggers
> it.
> 
> 
> > > Then most of the logic in crmsh would remain unchanged (i.e., it'd still
> > > operate on whole CIBs only), but the way how it passes it on to
> > > Pacemaker would improve. I hope.
> > crmsh currently doesn't keep the original copy of the CIB.
> 
> Right, but that should be a simple thing to add and prototype quickly.
> (Says he who isn't going to be the one doing it ;-)
> 
> > Anyway, this approach is worth investigating.
> 
> Thanks, let me know how it goes!
> 
> 
> Regards,
>     Lars
>