> Consulting the manual page for corosync.conf suggests that this option should belong to the link group only (as it's not prefixed with "knet_").
ip_version is not prefixed with knet_ in man corosync.conf so it does NOT belong to link options and it belongs to transport options.
Usage: knet link options are prefixed 'knet_'


It was agreed upon with corosync team that they will add the ip_version option to link options. The reasoning is for users to be able to set ip_version for each link separately. This is handy in a case node addresses are specified as names or FQDNs resolving to both IPv4 and IPv6. Then, with the link ip_version option specified, it is possible to make corosync use IPv4 in some links and IPv6 in others. Such behavior cannot be achieved with only single global ip_version option, that would set all links to resolve to either IPv4 or IPv6.


From a mailing discussion regarding bz1659389:
Tomas Jelinek:
I remember something like 9 months ago I asked how one totem.ip_version can work with knet where some links use IPv4 and others IPv6. The solution was to add ip_version option to each link. This seems to be still missing in corosync, though.

Jan Friesse:
Actually this is why ipv6-4 and ipv4-6 exists.

Tomas Jelinek:
Then we should drop support for interface.ip_version from pcs.

Jan Friesse:
Does it hurt anything? Maybe we will find that it's needed. Then we would need to implement support just in corosync and users wouldn't need to regenerate their config files.


Actually, it hurts something. Pcs should validate if specified node addresses match specified ip_version (bz1667053). If corosync ignored link.ip_version while pcs did not, we could get into a situation where totem.ip_version == ipv4, link.ip_version == ipv6 and addresses for such link are IPv6. Then pcs would be happy as addresses would match link.ip_version which has higher priority than totem.ip_version. However, corosync would not start as it would find out addresses do not match totem.ip_version while link.ip_version would be ignored by corosync.


So, we must either drop link.ip_version from pcs or add it to corosync.
Honza, what is your opinion about this?

Drop it from pcs then.

Created attachment 1539755 [details]
proposed fix + tests

After fix:

[root@rh80-node1:~]# pcs cluster setup myCluster rh80-node3 transport knet link ip_version=ipv4
No addresses specified for host 'rh80-node3', using 'rh80-node3'
Error: invalid link option 'ip_version', allowed options are: link_priority, linknumber, mcastport, ping_interval, ping_precision, ping_timeout, pong_count, transport
Error: Errors have occurred, therefore pcs is unable to continue
[root@rh80-node1:~]# echo $?
1

ip_version removed from link options in man pcs:
Transport knet:
Link options are: link_priority, linknumber, mcastport, ping_interval, ping_precision, ping_timeout, pong_count, transport (udp or sctp)

ip_version removed from link options in built-in help:
Transport knet:
Link options are:
    link_priority, linknumber, mcastport, ping_interval,
    ping_precision, ping_timeout, pong_count, transport (udp or sctp)

After fix:
[root@rhel81-node1 ~]# rpm -q pcs
pcs-0.10.1-6.el8.x86_64

[root@rhel81-node1 ~]# pcs cluster setup rhel-8.1-cluster rh81-1 transport knet link ip_version=ipv4
No addresses specified for host 'rh81-1', using 'rh81-1'
Error: invalid link option 'ip_version', allowed options are: link_priority, linknumber, mcastport, ping_interval, ping_precision, ping_timeout, pong_count, transport
Error: Errors have occurred, therefore pcs is unable to continue
[root@rhel81-node1 ~]# echo $?
1

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, 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-2019:3311