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

[Dejan Muhamedagic]

On Thu, Feb 28, 2013 at 11:03:02AM +0100, Lars Marowsky-Bree wrote:
> On 2013-02-25T12:20:13, "Brian J. Murrell" <brian at interlinx.bc.ca> wrote:
> 
> > > Perhaps there's a way to improve this.
> > 
> > Well, the CIB is shared resource.  Shared resources need to be locked
> > against these sort of racy updates.  Is there no locking of any kind at
> > any level of CIB modifying operations?
> 
> No. There's no CIB lock.
> 
> However, the CIB on the DC serializes all updates.
> 
> > i.e. does even cibadmin suffer from these last-write wins races with no
> > option or opportunity to lock the CIB?
> 
> Yes, if you use replace. If you instead apply a diff (incremental
> modification etc), those will be merged. (If they don't conflict at the
> XML level, obviously. And it doesn't protect against admins making
> contradictory changes to the configuration, but that's a different
> issue.)
> 
> I'm not sure if crm shell could be modified to instead submit a diff for
> the changes it made, or if that solved the problem.

crmsh used to make modifications in chunks, which was a bit
complex due to element dependencies, but it worked if I can
recall correctly. Then it got replaced by a full CIB replace
(everybody claimed that it was the right thing to do). Of
course, cmrsh know which elements got modified, which are new,
and which should be deleted. But I'm not sure cibadmin can
accept a diff of such a kind. Perhaps doing a shadow apply
instead of cibadmin -R would help?

Thanks,

Dejan