On 06/06/2013, at 3:45 PM, Vladislav Bogdanov <[email protected]> wrote:
> 06.06.2013 08:14, Andrew Beekhof wrote: >> >> On 06/06/2013, at 2:50 PM, Vladislav Bogdanov <[email protected]> wrote: >> >>> 06.06.2013 07:31, Andrew Beekhof wrote: >>>> >>>> On 06/06/2013, at 2:27 PM, Vladislav Bogdanov <[email protected]> wrote: >>>> >>>>> 05.06.2013 02:04, Andrew Beekhof wrote: >>>>>> >>>>>> On 05/06/2013, at 5:08 AM, Ferenc Wagner <[email protected]> wrote: >>>>>> >>>>>>> Dejan Muhamedagic <[email protected]> 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? >> >> The patch is applied on the server - so "cib" > > Ah, one more question. The whole modification request is rejected if any > of patch hunks fail, correct? Correct (and yes everything is serialized _unless_ you start using the -l cibadmin option) _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
