Description of problem:

In order to bootstrap a Galera cluster, the galera resource agent needs to retrieve the last sequence number of each galera node to find out which node is the most up-to-date.

For each galera node, the last sequence number is stored as a pacemaker attribute linked to the corresponding pacemaker node. There is currently
a 1-1 mapping between galera node's name and pacemaker node's name, and
the resource agent enforces that.

In case the galera server has to be started on a different network than
the one pacemaker is using, it is likely that both galera and pacemaker name
will differ (e.g. gcomm://overcloud-controller-0.internalapi.localdomain vs overcloud-controller-0.localdomain). If so, the resource agent will bail out
and the bootstrap will never finish.

Version-Release number of selected component (if applicable):
RHEL 7

How reproducible:
Always

Steps to Reproduce:
1. have galera nodes' name differ from pacemaker node
2. setup a galera resource with the appropriate wsrep_cluster_address
3. enable the galera resource

Actual results:
galera resource stuck is state "Slave", will never go "Master" in pacemaker

Expected results:
galera resource go "Master", i.e. galera cluster is bootstrapped