Red Hat Bugzilla – Bug 1025909
resource-agents-3.9.2-21.el6_4.8 upate break ocf:heartbeat:IPv6addr resource agent
Last modified: 2014-10-14 00:59:49 EDT
After resource-agents package udpate IPv6addr resource agent stop working bz989284-heartbeat-merger.patch seem to include code change breaking the resource agent. snippet from pcs config: Resource: ClusterIPv6 (class=ocf provider=heartbeat type=IPv6addr) Attributes: ipv6addr=2a00:1190:4:30::2/64 Operations: monitor start-delay=0 interval=15 timeout=15 (ClusterIPv6 monitor-15) This won't work after update and works if resource-agents package is downgraded to previous version. Relevant log: Nov 2 00:34:26 salamanca1 crmd[3189]: error: generic_get_metadata: Failed to retrieve meta-data for ocf:heartbeat:IPv6addr Nov 2 00:34:26 salamanca1 crmd[3189]: warning: get_rsc_metadata: No metadata found for IPv6addr::ocf:heartbeat: Input/output error (-5)
What a mistake from package maintainers - you actually removed IPv6addr resource agent - there is no other resource agent capable of handling IPv6 - IPaddr2 can be used to add IPv6 address but that's not supposed to happen - I'm original author of the IPaddr2 resource agent and it's full of ipv4 only code and it doesn't have any necessary code for handling IPv6. Please return working IPv6addr resource agent immediately - I'm quite sure you just broke all ipv6 capable clusters out there.
(In reply to Tuomo Soini from comment #2) > What a mistake from package maintainers - you actually removed IPv6addr > resource agent - there is no other resource agent capable of handling IPv6 - > IPaddr2 can be used to add IPv6 address but that's not supposed to happen > I'm original author of the IPaddr2 resource agent and it's full of ipv4 only > code and it doesn't have any necessary code for handling IPv6. What functionality specifically do you need that IPaddr2 does not provide. There has been quite a bit of effort upstream in the past year to make IPaddr2 ipv6 compatible. > Please return working IPv6addr resource agent immediately - I'm quite sure > you just broke all ipv6 capable clusters out there.
I can understand you want to support IPaddr2 only - but this is first time you introduced preliminary IPv6 support in IPaddr2 in same package update which removes IPv6addr. How could anybody do any transition from IPv6addr to IPaddr2 when same package update which add IPv6 support removes old resource agent. There need to be at least one one Y-release between these changes and tech notes noting about resource agents being removed on next release. Note: this change was done at rhel 6.4 - nobody would expect this kind of "resource agents get removed" change in same os release! It might be possible to switch to IPaddr2 with some testing. But you should revert that removing of resource agents in 6.4 !
I just tested IPaddr2 for ipv6 - that won't work because of errors in excludes - you excluded send_ua binary which is needed for IPv6 support to there is currently no working IPv6 capable address resource agent. You should REALLY test before release.
David, can you work with upstream to get the needed functionality from send_ua rolled into send_arp. It makes zero sense for it to be in a separate binary. Perhaps put it in a common .c file if they are concerned about duplication.
(In reply to Andrew Beekhof from comment #6) > David, can you work with upstream to get the needed functionality from > send_ua rolled into send_arp. It makes zero sense for it to be in a > separate binary. I'm not sure I agree. Keeping an IPv4 tool and a IPv6 tool isolated into separate binaries seems like the right path forward. They share no code overlap. ARP != IPv6 neighbor discovery using unsolicited advertisements. They are only related in concept. send_arp also has multiple implementations depending on what libraries are involved. I'd rather not complicate that code any further. > Perhaps put it in a common .c file if they are concerned about duplication. I'm going to move forward with a common .c file shared between IPv6addr.c and a new send_ua.c file.
We never supported IPv6addr resource agents in RHEL6 as the technology was tech preview. So this is rather a non-issue in itself. I agree that IPv6 is a must for IPaddr2 and must be addressed ASAP. It's not possible to do it right away in rhel6.5 but we can zstream the fix.
(In reply to Tuomo Soini from comment #4) > I can understand you want to support IPaddr2 only - but this is first time > you introduced preliminary IPv6 support in IPaddr2 in same package update > which removes IPv6addr. > > How could anybody do any transition from IPv6addr to IPaddr2 when same > package update which add IPv6 support removes old resource agent. There need > to be at least one one Y-release between these changes and tech notes noting > about resource agents being removed on next release. > > Note: this change was done at rhel 6.4 - nobody would expect this kind of > "resource agents get removed" change in same os release! > > It might be possible to switch to IPaddr2 with some testing. But you should > revert that removing of resource agents in 6.4 ! Tuomo, you need to tone down a bit. pacemaker and related resource agents were never fully supported in RHEL prior to this update. IF you have decided to put production clusters on non supported software, it's your and only your choice to take the risk. Red Hat does not guarantee continuity of Tech Preview releases.
Tuomo, also please file a ticket with Global Support Services and have them associate your case with this bugzilla.
I think you misunderstood - I am giving you support and help in this case.
(In reply to Tuomo Soini from comment #11) > I think you misunderstood - I am giving you support and help in this case. No, you misunderstand my request. I asked you to file a ticket with GSS so that we can track your request and associate it with your customer account. This way you will be notified immediately of progress of this bug.
I'm no rhel customer :-)
(In reply to David Vossel from comment #7) > (In reply to Andrew Beekhof from comment #6) > > David, can you work with upstream to get the needed functionality from > > send_ua rolled into send_arp. It makes zero sense for it to be in a > > separate binary. > > I'm not sure I agree. Keeping an IPv4 tool and a IPv6 tool isolated into > separate binaries seems like the right path forward. They share no code > overlap. ARP != IPv6 neighbor discovery using unsolicited advertisements. > They are only related in concept. Sounds not unlike having IPaddr2 support ipv6. That the underlying implementation is different is only a detail the developers care about.
(In reply to Andrew Beekhof from comment #14) > (In reply to David Vossel from comment #7) > > (In reply to Andrew Beekhof from comment #6) > > > David, can you work with upstream to get the needed functionality from > > > send_ua rolled into send_arp. It makes zero sense for it to be in a > > > separate binary. > > > > I'm not sure I agree. Keeping an IPv4 tool and a IPv6 tool isolated into > > separate binaries seems like the right path forward. They share no code > > overlap. ARP != IPv6 neighbor discovery using unsolicited advertisements. > > They are only related in concept. > > Sounds not unlike having IPaddr2 support ipv6. > That the underlying implementation is different is only a detail the > developers care about. True, but arp is something very specific to IPv4. We'd have to re-name send_arp to something else, and merge this send_ua logic in with it. Not a bad idea, but because send_arp has multiple implementations this is not straightforward either. Regardless if we decide to merge the send_* binaries into something new at some point, the first step there would be splitting out the send_ua logic into some util file that can be re-used. Having a send_ua tool that is not built with IPv6addr gets us a step closer to this.
there is a pull request related to this issue upstream https://github.com/ClusterLabs/resource-agents/pull/347
Tested IPaddr2 with send_ua binary in place. Works fine with IPv6 - good work with that. Indeed this change makes IPv6addr unnecessary.
I have verified that it is possible to use ipv6 addresses with IPaddr agent resource-agents-3.9.5-11.el6.x86_64 # export \ OCF_FUNCTIONS_DIR=/usr/lib/ocf/lib/heartbeat \ OCF_RESKEY_ip=fe80::1800:ff:fe00:85 \ OCF_RESKEY_nic=eth1 # /usr/lib/ocf/resource.d/heartbeat/IPaddr status running # /usr/lib/ocf/resource.d/heartbeat/IPaddr stop INFO: IP status = ok, IP_CIP= # /usr/lib/ocf/resource.d/heartbeat/IPaddr status stopped # /usr/lib/ocf/resource.d/heartbeat/IPaddr start INFO: Adding inet6 address fe80::1800:ff:fe00:85/64 to device eth1 INFO: Bringing device eth1 up INFO: /usr/libexec/heartbeat/send_ua -i 200 -c 5 fe80::1800:ff:fe00:85 64 eth1 # rpm -qf /usr/libexec/heartbeat/send_ua resource-agents-3.9.5-11.el6.x86_64 # /usr/lib/ocf/resource.d/heartbeat/IPaddr monitor # echo $? 0 # /usr/lib/ocf/resource.d/heartbeat/IPaddr status running # ip -6 a show eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 ... inet6 fe80::1800:ff:fe00:85/64 scope link valid_lft forever preferred_lft forever
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. http://rhn.redhat.com/errata/RHBA-2014-1428.html