Bug 1674005
| Summary: | ip_version incorrectly listed as knet link option | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Patrik Hagara <phagara> | ||||
| Component: | pcs | Assignee: | Tomas Jelinek <tojeline> | ||||
| Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 8.0 | CC: | cfeist, cluster-maint, idevat, jfriesse, mlisik, nhostako, omular, tojeline | ||||
| Target Milestone: | rc | ||||||
| Target Release: | 8.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | pcs-0.10.1-6.el8 | Doc Type: | Bug Fix | ||||
| Doc Text: |
Cause:
User configures ip_version for corosync links.
Consequence:
Corosync ignores the ip_version value and only uses global ip_version value. Resulting corosync behavior does not match user's expectation based on entered options of pcs cluster setup command.
Fix:
Make pcs reject ip_version in link options.
Result:
Pcs does not put bogus ip_version in corosync links configuration.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-11-05 20:39:40 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1682129 | ||||||
| Bug Blocks: | 1667053 | ||||||
| Attachments: |
|
||||||
> 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 |
Description of problem: The pcs manual page, in section documenting the "pcs cluster setup" command with knet transport, mentions the "ip_version" option in both transport and link option lists: > Transport knet: > This is the default transport. It allows configuring traffic encryption and compression as well as using multiple addresses (links) for nodes. > Transport options are: ip_version, knet_pmtud_interval, link_mode > Link options are: ip_version, link_priority, linknumber, mcastport, ping_interval, ping_precision, ping_timeout, pong_count, transport (udp or sctp) > [...] > Transports and their options, link, compression, crypto and totem options are all documented in corosync.conf(5) man page; knet link options are > prefixed 'knet_' there, compression options are prefixed 'knet_compression_' and crypto options are prefixed 'crypto_'. Quorum options are > documented in votequorum(5) man page. 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_"). Version-Release number of selected component (if applicable): pcs-0.10.1-4.el8.x86_64 How reproducible: always Steps to Reproduce: 1. man pcs 2. man corosync.conf Actual results: uncertainty and confusion Expected results: clear documentation Additional info: