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 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.

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

Reply via email to