RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1025909 - resource-agents-3.9.2-21.el6_4.8 upate break ocf:heartbeat:IPv6addr resource agent
Summary: resource-agents-3.9.2-21.el6_4.8 upate break ocf:heartbeat:IPv6addr resource ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: resource-agents
Version: 6.4
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: David Vossel
QA Contact: Cluster QE
URL:
Whiteboard: 0day
Depends On:
Blocks: 1027411 1027412
TreeView+ depends on / blocked
 
Reported: 2013-11-01 23:07 UTC by Tuomo Soini
Modified: 2014-10-14 04:59 UTC (History)
12 users (show)

Fixed In Version: resource-agents-3.9.2-41.el6
Doc Type: Bug Fix
Doc Text:
Previously, the IPaddr2 agent did not send out unsolicited neighbor advertisements to announce a link-layer address change. Consequently, floating IPv6 addresses, which require this functionality, could not work correctly. To fix this bug, the send_ua internal binary required for IPaddr2 agent to drive IPv6 addresses has been added. As a result, the floating IPv6 addresses now work correctly, and IPv4 addresses are left unaffected by this change.
Clone Of:
Environment:
Last Closed: 2014-10-14 04:59:49 UTC
Target Upstream Version:
Embargoed:
tis: needinfo-

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 637963 0 None None None Never
Red Hat Product Errata RHBA-2014:1428 0 normal SHIPPED_LIVE resource-agents bug fix and enhancement update 2014-10-14 01:06:18 UTC

Description Tuomo Soini 2013-11-01 23:07:36 UTC 
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)
Comment 2 Tuomo Soini 2013-11-01 23:31:31 UTC 
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.
Comment 3 David Vossel 2013-11-02 04:13:00 UTC 
(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.
Comment 4 Tuomo Soini 2013-11-02 09:37:28 UTC 
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 !
Comment 5 Tuomo Soini 2013-11-03 17:52:06 UTC 
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.
Comment 6 Andrew Beekhof 2013-11-04 09:09:13 UTC 
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.
Comment 7 David Vossel 2013-11-04 15:37:27 UTC 
(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.
Comment 8 Fabio Massimo Di Nitto 2013-11-04 16:39:07 UTC 
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.
Comment 9 Fabio Massimo Di Nitto 2013-11-04 16:42:45 UTC 
(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.
Comment 10 Fabio Massimo Di Nitto 2013-11-04 16:46:07 UTC 
Tuomo,

also please file a ticket with Global Support Services and have them associate your case with this bugzilla.
Comment 11 Tuomo Soini 2013-11-04 17:41:36 UTC 
I think you misunderstood - I am giving you support and help in this case.
Comment 12 Fabio Massimo Di Nitto 2013-11-04 17:48:43 UTC 
(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.
Comment 13 Tuomo Soini 2013-11-04 18:15:05 UTC 
I'm no rhel customer :-)
Comment 14 Andrew Beekhof 2013-11-04 20:24:22 UTC 
(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.
Comment 15 David Vossel 2013-11-04 22:16:58 UTC 
(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.
Comment 16 David Vossel 2013-11-04 22:19:48 UTC 
there is a pull request related to this issue upstream

https://github.com/ClusterLabs/resource-agents/pull/347
Comment 18 Tuomo Soini 2013-11-05 16:07:51 UTC 
Tested IPaddr2 with send_ua binary in place. Works fine with IPv6 - good work with that. Indeed this change makes IPv6addr unnecessary.
Comment 24 michal novacek 2014-07-23 14:36:51 UTC 
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
Comment 25 errata-xmlrpc 2014-10-14 04:59:49 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.