[ClusterLabs] [corosync][pacemaker] runtime issues, while it builds OK
Bogdan Dobrelya
bdobrelia at mirantis.com
Thu Jun 30 09:26:45 UTC 2016
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
More information about the Users
mailing list