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

[Dejan Muhamedagic]

On Fri, Feb 22, 2013 at 11:48:58AM +1100, Andrew Beekhof wrote:
> On Fri, Feb 22, 2013 at 5:18 AM, Brian J. Murrell <brian at interlinx.bc.ca> wrote:
> > I wonder what happens in the case of two racing "crm" commands that want
> > to update the CIB (with non-overlapping/conflicting data).  Is there any
> > locking to ensure that one crm cannot overwrite the other's change?
> > (i.e. second one to get there has to read in the new CIB before being
> > able to apply his change and send it back)  Or if there is a situation
> > where one write stomps another's,
> 
> If my information is up-to-date, yes.
> 
> crmsh uses a read+modify+replace cycle, if B reads after A has read
> but before the replace has happened, data will be lost.

Before doing replace, crmsh queries the CIB and checks if the
epoch was modified in the meantime. Those operations are not
atomic, though. Perhaps there's a way to improve this. However
...


> > is there at least some kind of
> > notification?
> 
> i dont think so
> 
> > Ultimately, it would be bad for two nodes for example to issue:
> >
> > # crm node attribute $(uname -n) set name value
> >
> > at the same time and have one of those updates lost.

crm node/crm resource invoke crm_attribute or other crm_ tools.

> > But that's what I think I am seeing.

You should file a bugzilla then.

Thanks,

Dejan

> > Cheers,
> > b.
> >
> >
> > _______________________________________________
> > Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> >
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> > Bugs: http://bugs.clusterlabs.org
> >
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org