[Pacemaker] Build dlm_controld for pacemaker stack (dlm_controld.pcmk)

Bernardo Cabezas Serra bcabezas at apsl.net
Tue Oct 30 06:03:32 EDT 2012

El 2012-10-30 09:15, Vladislav Bogdanov escribió:

> What exactly errors do you see? Pacemaker APIs used there received 
> some
> changes between 1.1.7 and 1.1.8.

I was doing things wrong, mixing suse dlm code with upstream pacemaker 
versions, and got lots of API errors, I think are not relevant, thanks. 
Also with pacemaker suse's patched version got other kind of compilation 

I think we will use our current  cman/corosync14/ocfs2 stack, but 
before I will try to compile corosync2/dlm4/ with GFS2, as you suggest 
in answer to David.
If this stuff works well, I will evaluate to switch to this version, as 
seems more "upstream" and future version than cman/corosync14.

>I have one more patch which I tried
> with pacemaker master Aug 22 (close enough to 1.1.8, but some APIs
> changed again after that point). That version did not work for me 
> with
> corosync14 because of bug fixed after that and I decided to move to
> corosync2 right after that failure to be more upstream-compatible. I
> can't say if it help you, but you may want to try. Should I post it?

Thanks, but will try other option as stated :)

> [...]
> I suspect that ocfs_controld.pcmk (like gfs_controld.pcmk in 3.0.17)
> still uses that old way. If that is true, then it can't work 
> reliably. I
> tried to port gfs_controld to use stonith-ng with corosync1/openais
> (included in the patch I talk about above), but I did not test it at 
> all
> (although I just ported it to corosync2/dlm4 and it works in a 
> testing
> setup, see my answer to David).

Will give a try to it.
I understand the main source form dlm4 is this one, isn't it?

Does not use autotools, and configure script does not detect correctly 
my kernel version, but thanks to your comments now I understand why it 
does need kernel sources. Will try to make it work...

Thanks a lot

More information about the Pacemaker mailing list