Bug 1743373

We'll primarily target RHEL 8 for this (via Bug 1743377). Once that's ready, we can see how feasible it would be to backport to RHEL 7 and whether it would be allowed at that stage of the life cycle.

Fixed in upstream 1.1 branch by commits 86079a2a and 9ae6903e

The ability is enabled via a new environment variable:

# If the Pacemaker Remote service is run on the local node, it will listen
# for connections on this address. The value may be a resolvable hostname or an
# IPv4 or IPv6 numeric address. When resolving names or using the default
# wildcard address (i.e. listen on all available addresses), IPv6 will be
# preferred if available. When listening on an IPv6 address, IPv4 clients will
# be supported (via IPv4-mapped IPv6 addresses).
# PCMK_remote_address="192.0.2.1"

The environment variable can be specified in /etc/sysconfig/pacemaker for cluster nodes and Pacemaker Remote nodes. For bundles, any sysconfig-like file on the host can be mapped into the container as /etc/pacemaker/pcmk-init.env (using pcs's existing storage-map option for bundles), and Pacemaker Remote inside the bundle will load the environment variables from it.

*** Bug 1759079 has been marked as a duplicate of this bug. ***

qa_ack+, same repro steps as https://bugzilla.redhat.com/show_bug.cgi?id=1743377#c8

> [root@virt-164 ~]# rpm -q pacemaker pacemaker-remote
> pacemaker-1.1.23-1.el7.x86_64
> pacemaker-remote-1.1.23-1.el7.x86_64
> [root@virt-164 ~]# systemctl enable --now pacemaker_remote
> Created symlink from /etc/systemd/system/multi-user.target.wants/pacemaker_remote.service to /usr/lib/systemd/system/pacemaker_remote.service.
> [root@virt-164 ~]# ss -ltnp | grep pacemaker
> LISTEN     0      10        [::]:3121                  [::]:*                   users:(("pacemaker_remot",pid=30346,fd=8))

listening on all interfaces by default


now change the PCMK_remote_address variable to bind to specific IP:

> [root@virt-164 ~]# ip addr show dev eth0
<snip>
>     inet 10.37.167.35/22 brd 10.37.167.255 scope global noprefixroute dynamic eth0
<snip>
> [root@virt-164 ~]# grep PCMK_remote_address /etc/sysconfig/pacemaker 
> PCMK_remote_address="10.37.167.35"
> [root@virt-164 ~]# systemctl restart pacemaker_remote
> [root@virt-164 ~]# ss -ltnp | grep pacemaker
> LISTEN     0      10     10.37.167.35:3121                     *:*                   users:(("pacemaker_remot",pid=30290,fd=8))


stop and disable pacemaker_remote.service:

> [root@virt-164 ~]# systemctl disable --now pacemaker_remote


authorize to remote node IPv4 address from existing cluster:

> [root@virt-160 ~]# pcs cluster auth 10.37.167.35
> Username: hacluster
> Password: 
> 10.37.167.35: Authorized


add the remote node using the listen IP address:

> [root@virt-160 ~]# pcs cluster node add-remote 10.37.167.35 virt-164
> Sending remote node configuration files to '10.37.167.35'
> 10.37.167.35: successful distribution of the file 'pacemaker_remote authkey'
> Requesting start of service pacemaker_remote on '10.37.167.35'
> 10.37.167.35: successful run of 'pacemaker_remote enable'
> 10.37.167.35: successful run of 'pacemaker_remote start'


verify that the remote node joined the cluster:

> [root@virt-160 ~]# pcs status
> Cluster name: STSRHTS23819
> Stack: corosync
> Current DC: virt-163 (version 1.1.23-1.el7-9acf116022) - partition with quorum
> Last updated: Tue Jun 16 16:51:24 2020
> Last change: Tue Jun 16 16:51:19 2020 by root via cibadmin on virt-160
> 
> 4 nodes configured
> 5 resource instances configured
> 
> Online: [ virt-160 virt-162 virt-163 ]
> RemoteOnline: [ virt-164 ]
> 
> Full list of resources:
> 
>  fence-virt-160	(stonith:fence_xvm):	Started virt-162
>  fence-virt-162	(stonith:fence_xvm):	Started virt-163
>  fence-virt-163	(stonith:fence_xvm):	Started virt-163
>  fence-virt-164	(stonith:fence_xvm):	Started virt-160
>  virt-164	(ocf::pacemaker:remote):	Started virt-160
> 
> Daemon Status:
>   corosync: active/enabled
>   pacemaker: active/enabled
>   pcsd: active/enabled



(In reply to Ken Gaillot from comment #4)
> For bundles, any sysconfig-like
> file on the host can be mapped into the container as
> /etc/pacemaker/pcmk-init.env (using pcs's existing storage-map option for
> bundles), and Pacemaker Remote inside the bundle will load the environment
> variables from it.

@Pini: Could you please verify this also works for OpenStack (with bundles ^)? Should be similar to bz#1743377 from 8.2.0. Feel free to flip to verified afterwards.

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 (pacemaker bug fix and enhancement update), 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-2020:3951