06.06.2013 07:31, Andrew Beekhof wrote: > > On 06/06/2013, at 2:27 PM, Vladislav Bogdanov <bub...@hoster-ok.com> wrote: > >> 05.06.2013 02:04, Andrew Beekhof wrote: >>> >>> On 05/06/2013, at 5:08 AM, Ferenc Wagner <wf...@niif.hu> wrote: >>> >>>> Dejan Muhamedagic <deja...@fastmail.fm> writes: >>>> >>>>> On Mon, Jun 03, 2013 at 06:19:06PM +0200, Ferenc Wagner wrote: >>>>> >>>>>> I've got a script for resource creation, which puts the new resource in >>>>>> a shadow CIB together with the necessary constraints, runs a simulation >>>>>> and finally offers to commit the shadow CIB into the live config (by >>>>>> invoking an interactive crm). This works well. My concern is that if >>>>>> somebody else (another cluster administrator) changes anything in the >>>>>> cluster configuration between creation of the shadow copy and the >>>>>> commit, those changes will be silently reverted (lost) by the commit. >>>>>> Is there any way to avoid the possibility of this? According to >>>>>> http://article.gmane.org/gmane.linux.highavailability.pacemaker/11021, >>>>>> crm provides this functionality for its configure sessions [*], but the >>>>>> shadow CIB route has good points as well (easier to script via cibadmin, >>>>>> simulation), which I'd like to use. Any ideas? >>>>> >>>>> Record the two epoch attributes of the cib tag at the beginning >>>>> and check if they changed just before applying the changes. >>>> >>>> Maybe I don't understand you right, but isn't this just narrowing the >>>> time window of the race? After all, that concurrent change can happen >>>> between the epoch check and the commit, can't it? >>> >>> The CIB will refuse to accept any update with a "lower" version: >>> >>> >>> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/_configuration_version.html >> >> I recall that LDAP has similar problem, which is easily worked around >> with specifying two values, one is original, second is new. >> That way you tell LDAP server: >> Replace value Y in attribute X to value Z. And if value is not Y at the >> moment of modification request, then command fails. > > "cibadmin --patch" works this way
Who is baking new CIB in that case, cibadmin or cib? _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
