So from an initial look this is the downstream ipv6 manifestation of this bug https://bugs.launchpad.net/tripleo/+bug/1657108/. The super short version is that if we start off an image that has prepopulated /etc/sysconfig/ip[6]tables rules (and the iptables package does ship such rules that only allow ssh and icmp), pcs will be executed when the firewall modules has not yet kicked in to open up the pacemaker/pcs ports and so it will fail.
To verify/disprove this theory can you try the following on the undercloud:
echo '' > /tmp/iptables
echo '' > /tmp/ip6tables
virt-copy-in -a overcloud-full.qcow2 /tmp/iptables /etc/sysconfig/
virt-copy-in -a overcloud-full.qcow2 /tmp/ip6tables /etc/sysconfig/
openstack overcloud image upload --image-path . --update-existing
And then try and redeploy? Note that we already have fixes in order to empty these stock rules from the image building process. I assume that they have not yet hit downstream, because if that were the case we would not see the entries in ip[6]tables at comment 5.

(In reply to Michele Baldessari from comment #7)
> And then try and redeploy? Note that we already have fixes in order to empty
> these stock rules from the image building process. I assume that they have
> not yet hit downstream, because if that were the case we would not see the
> entries in ip[6]tables at comment 5.
I am confirming Michele's assumption - The deployment was successful after placing empty iptables rules into overcloud image and relabeling selinux.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHEA-2017:1245

Note

You need to
log in
before you can comment on or make changes to this bug.