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.
The epoch attributes are loaded at the time the CIB is loaded. Refreshed after commit or refresh. > 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. Yes, it does. I just wonder how much performance would be affected. > May be there is a better way to not loose big edits due to some small > unrelated changes were made meanwhile? The one you proposed above seems to be the most straightforward. > Or may be you can describe algorithm you use for those who do not know > python? Not much of an algorithm. The loaded CIB is saved to a file, then, at the commit time, a diff is constructed between the new configuration and the saved one. > > I didn't remove the check for the changes and anyway cib is > > going to refuse to apply the patch if the epoch is older. Of > > course, crmsh can set the epoch attribute to something greater > > than the current epoch. > > Didn't get this, sorry. Could you please reword? The idea was that the crmsh can enforce a greater epoch and then see if the patch applies. Otherwise, cib refuses to apply patches with older epochs (I wonder if that is really necessary, i.e. perhaps the epoch should be ignored when patching). Cheers, Dejan > > What would you suggest? > > > > Cheers, > > > > Dejan > > > >> Vladislav > >> > >> _______________________________________________ > >> Linux-HA mailing list > >> [email protected] > >> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >> See also: http://linux-ha.org/ReportingProblems > > _______________________________________________ > > Linux-HA mailing list > > [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > See also: http://linux-ha.org/ReportingProblems > > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
