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

[Bernardo Cabezas Serra]

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

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?
http://git.fedorahosted.org/git/dlm.git

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