Description of problem:

As described in bug 1659269 and bug 1654630 corosync has quite a few problems with reliable resolve of hostname. We now should have a quite good solution which will work most of the time, but it's still not perfect a may require changes in corosync.conf.

Basically there are two problems which are in contradiction:
- Corosync doesn't force ip order - but then we hit bug 1654630
- Corosync force ip order - then we hit bug 1659269

Pseudo solution would be to define order as a ip4 then ip6 (because most of the people use ipv4 as a primary ip family), but then ip6 setups will be hit.

PCS cluster setup has a big advantage of being executed on fully booted system, so it doesn't hit the bug 1654630. It can also check that list of all nodes IPs is equal on all nodes (or at least this was my impression on Monday 10.12.2008 call). This also means that pcs is already doing resolving.

Having said all of above, I would like to ask you to consider storing resolved IPs in corosync.conf for ringX_addr fields (of course with option to disable this new default behavior and store hostname).


Actual results:
# pcs cluster setup test node_name

corosync.conf:

    node {
        ring0_addr: node_name
        name: node_name
        nodeid: 1
    }

Expected results:

corosync.conf:

    node {
        ring0_addr: node_ip
        name: node_name
        nodeid: 1
    }