Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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

This was already addressed by the resource agent by Damien's introduction of the cluster_host_map parameter.