Description of problem:

In my test cluster, node 2's hostname is "fastvm-rhel-8-0-24". Its node name (from pacemaker's point of view) is "node2". The result is that we try to get duplicate sosreports.

[root@fastvm-rhel-8-0-24 ~]# sos collect --batch
...
Cluster type set to Pacemaker High Availability Cluster Manager

The following is a list of nodes to collect from:
	fastvm-rhel-8-0-24
	node2


Connecting to nodes...

Beginning collection of sosreports from 2 nodes, collecting a maximum of 4 concurrently

fastvm-rhel-8-0-24  : Generating sosreport...
fastvm-rhel-8-0-24 : Generating sosreport...
client_loop: send disconnect: Broken pipe

(The "Broken pipe" is because the system hung and got fenced.)

-----

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

sos-4.1-9.el8_5

-----

How reproducible:

Always

-----

Steps to Reproduce:
1. Configure a pacemaker cluster where a node's hostname differs from its node name.
2. Run `sos collect` from that node.

-----

Actual results:

sos collector tries to get two sosreports from the local host: one from its hostname, one from its node name.

-----

Expected results:

sos collector tries to get only one sosreport from the local host.

-----

Additional info:

I suggest that we abandon adding the local host to our node list altogether. Instead, we could get a list from pacemaker (falling back to corosync) in every case. That would actually be a lot easier than fixing the "filter out the local hostname" process, if there's no problem with that. Here's why.

If pacemaker is running on the local host, then you can easily get the local pacemaker node name by running `crm_node -n`. For example:
~~~
[root@fastvm-rhel-8-0-24 ~]# crm_node -n
node2
~~~

However, if pacemaker is not running, then Bug 2065811 proposes that we fall back to corosync.conf. In that case, mapping the local host's hostname to its pacemaker node name is not nearly as straightforward. `crm_node -n` doesn't work if pacemaker isn't running. And the corosync config display commands don't work if corosync isn't running.

This is the nodelist section of corosync.conf:
~~~
nodelist {
    node {
        ring0_addr: node1
        name: node1
        nodeid: 1
    }

    node {
        ring0_addr: node2
        name: node2
        nodeid: 2
    }
}
~~~


We need to discover that fastvm-rhel-8-0-24 is the same thing as the "name" node2. "name" is what we need, but we can't count on using it during the search. "name" is not necessarily a hostname that resolves. ringX_addr (there can be multiple addrs, with ring0 being the primary) is either a hostname that should resolve or an IP address. In the below example I've configured the cluster with names "bad_node1" and "bad_node2" (which don't resolve) and with ring_addrs "node1" and "node2" (which do resolve).
~~~
[root@fastvm-rhel-8-0-24 ~]# pcs status | grep Online
  * Online: [ bad_node1 bad_node2 ]

[root@fastvm-rhel-8-0-24 ~]# cat /etc/corosync/corosync.conf
...
nodelist {
    node {
        ring0_addr: node1
        name: bad_node1
        nodeid: 1
    }

    node {
        ring0_addr: node2
        name: bad_node2
        nodeid: 2
    }
}
~~~


A naive idea is connecting to each ringX_addr in the list to determine which one is the local node, and then grabbing the corresponding "name"... which is slow, sounds terrible, and will fail if the address is down.

The corosync.conf man page says:
~~~
       name   This option is used mainly with knet transport to identify local node.  It's also used by client software (pacemaker).  Algorithm for identifying local node is following:

              1.     Looks up $HOSTNAME in the nodelist

              2.     If this fails strip the domain name from $HOSTNAME and looks up that in the nodelist

              3.     If this fails look in the nodelist for a fully-qualified name whose short version matches the short version of $HOSTNAME

              4.     If all this fails then search the interfaces list for an address that matches a name in the nodelist
~~~