On Thu, Feb 28, 2013 at 11:03:02AM +0100, Lars Marowsky-Bree wrote: > On 2013-02-25T12:20:13, "Brian J. Murrell" <br...@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 _______________________________________________ Pacemaker mailing list: Pacemaker@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
