[ClusterLabs] [corosync][pacemaker] runtime issues, while it builds OK

[Bogdan Dobrelya]

On 06/30/2016 11:16 AM, Bogdan Dobrelya wrote:
> Hello.
> I'm building the libqb -> corosync -> pacemaker and commit each as a
> separate docker container layer. Then I run the latter and spawn a
> corosync with a simple config, then a pacemaker instance.
> 
> The issue is, that when I just run processes, the pacemaker complains
> it has an ipc issues (strace dump):
> 
> connect(6, {sa_family=AF_LOCAL, sun_path=@"corosync.ipc"}, 110) = -1
> ECONNREFUSED (Connection refused)
> 
> According to that I've found on that topic, it seems related to the
> wrong libqb/corosync versions the pacemaker app was build for.
> 
> BUT, if I first *rebuild* libqb -> corosync -> pacemaker, then
> *relaunch* corosync -> pacemaker, it works like a charm! I have no
> explanation to that strange magic. Any ideas, why it is so?
> 
> Ofc, I can w/a that by a containers entry point like:
> a corosync: build libqb -> corosync, then launch
> a pacemaker: build libqb -> corosync -> pacemaker, then launch
> 
> But that'd be a really ugly band aiding and is a very long to start as well.
> 
> Note, the libqb/corosync builds are from a signed tarballs, the
> pacemaker - from its github tag checked-out as I want to "play" with a
> latest builds from trunc.
> 

Hm, it seems the issue is with the artifacts make produces then I
execute a libqb->corosync->pacemaker chain. If I build containers from
mounted repos, throwing them out at the commit stage and leaving only
the resulting artifacts, I have that strange behavior I've described
above. But if I commit the build dirs into containers as well, it starts
working w/o additional runtime rebuilds!

I thought the artifacts make produces are self contained. It seems they
are not :(


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando