28.06.2013 17:47, Dejan Muhamedagic wrote: > On Thu, Jun 27, 2013 at 11:38:13AM +0300, Vladislav Bogdanov wrote: >> 26.06.2013 18:30, Dejan Muhamedagic wrote: >>> On Wed, Jun 26, 2013 at 06:13:33PM +0300, Vladislav Bogdanov wrote: >>>> 26.06.2013 15:57, Dejan Muhamedagic wrote: >>>>> On Thu, Jun 06, 2013 at 05:19:03PM +0200, Dejan Muhamedagic wrote: >>>>>> Hi, >>>>>> >>>>>> On Thu, Jun 06, 2013 at 03:11:16PM +0300, Vladislav Bogdanov wrote: >>>>>>> 06.06.2013 08:43, Vladislav Bogdanov wrote: >>>>>>> [...] >>>>>>>>>>>> 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" >>>>>>>> >>>>>>>> Then that is safe way to go, assuming that cib daemon serializes >>>>>>>> modification requests. >>>>>>>> >>>>>>> >>>>>>> It would be great if crmsh use that trick. >>>>>> >>>>>> Hope to have something soon. Stay tuned. >>>>> >>>>> The patch for crmsh is attached and you'll need the very latest >>>>> pacemaker (because cibadmin needed some fixing). Unfortunately, >>>>> I cannot push this yet to the repository, as the current >>>>> pacemaker 1.1.10-rc still identifies itself as 1.1.9. I'd >>>>> appreciate if you could test it. >>>> >>>> Seems to work during preliminary testing (stop clone with crm configure >>>> edit and then start it with crm resource start). >>>> cib process on the DC reports it received the diff and handles that >>>> perfectly. >>>> >>>> Thank you! >>>> >>>> I'll build updated package with this patch tomorrow and try to put that >>>> into real work. >>>> I mean to try concurrent updates. >>>> What would be the best way to achieve them? >>>> >>>> Is starting editing with crm configure edit with some concurrent command >>>> during that editing is enough (and save after command is run)? >>> >> >> I meant to ask when does crmsh gets original epoch to construct diff, at >> the very beginning of editing, or right before commiting - there can be >> rather big timeframe between that points. >> >> It would be nice to have an intelligent "patcher" which takes one CIB >> snapshot at the beginning of edit, than generates a diff and looks if it >> applies to a current CIB cleanly (all except epoch). Then it would be >> possible to use current epoch in a diff which goes to a cib daemon. >> I do not know does it make a sense. >> >> May be there is a better way to not loose big edits due to some small >> unrelated changes were made meanwhile? >> >> Or may be you can describe algorithm you use for those who do not know >> python? > > The alogorithm is in cibconfig.py:_patch_cib(). But nothing > very interesting there. > > If you want to test here's a new patch. It does work with > unrelated changes happening in the meantime. I didn't test yet > really concurrent updates. > > Again: Please use this patch _only_ with the latest v1.1.10.
Thanks, I included it into my build, will look. Vladislav _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
