Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
The aws-vpc-move-ip resource agent's normal start operation throws errors that may lead users to think there was a problem.
stderr: RTNETLINK answers: Cannot assign requested address
stderr: Nov 09 02:38:24 WARNING: command failed, rc 2
These errors come from the ec2ip_drop() function. The start function calls ec2ip_get_and_configure(), which in turn calls ec2ip_drop() to delete the IP address immediately before adding it again. The errors shown above are thrown when the ec2ip_drop() runs `ip addr delete` against the managed IP address, which is not yet assigned.
~~~
ec2ip_drop() {
cmd="ip addr delete ${OCF_RESKEY_ip}/32 dev $OCF_RESKEY_interface"
ocf_log debug "executing command: $cmd"
$cmd
rc=$?
if [ "$rc" -gt 0 ]; then
ocf_log warn "command failed, rc $rc"
return $OCF_ERR_GENERIC
fi
~~~
Under normal circumstances, this command will always fail during the start operation.
We have three valid options here:
1) Print the stdout and stderr from `ip addr delete` at only a debug level for the start operation.
2) Do not print the stdout and stderr from the ec2ip_drop() function at all for the start operation.
3) Remove the ec2ip_drop() call from the ec2ip_get_and_configure() function.
- The ec2ip_get_and_configure() function should only be called when the IP address is **not** already assigned and up.
- The ec2ip_get_and_configure() function calls ec2ip_drop() to delete the IP address and then immediately re-adds it.
I favor option #1 just in case of unforeseen edge cases.
-----
Version-Release number of selected component (if applicable):
resource-agents-4.1.1-68.el8.x86_64
master
-----
How reproducible:
Always
-----
Steps to Reproduce:
1. Create an aws-vpc-move-ip resource in disabled state.
2. Attempt to debug-start the resource (or enable it and check the logs).
-----
Actual results:
Operation start for aws-vip (ocf:heartbeat:aws-vpc-move-ip) returned: 'ok' (0)
> stderr: Nov 09 02:38:20 INFO: EC2: Moving IP address 10.0.1.65 to this host by adjusting routing table rtb-01b4ea1ae0ec0a4d9
> stderr: Nov 09 02:38:20 INFO: monitor: check routing table (API call) - rtb-01b4ea1ae0ec0a4d9
> stderr: Nov 09 02:38:22 WARNING: IP 10.0.1.65 not assigned to running interface
> stderr: Nov 09 02:38:22 INFO: EC2: Adjusting routing table and locally configuring IP address
> stderr: RTNETLINK answers: Cannot assign requested address
> stderr: Nov 09 02:38:24 WARNING: command failed, rc 2
> stderr: Nov 09 02:38:24 INFO: monitor: check routing table (API call) - rtb-01b4ea1ae0ec0a4d9
-----
Expected results:
Operation start for aws-vip (ocf:heartbeat:aws-vpc-move-ip) returned: 'ok' (0)
> stderr: Nov 09 02:40:43 INFO: EC2: Moving IP address 10.0.1.65 to this host by adjusting routing table rtb-01b4ea1ae0ec0a4d9
> stderr: Nov 09 02:40:43 INFO: monitor: check routing table (API call) - rtb-01b4ea1ae0ec0a4d9
> stderr: Nov 09 02:40:44 INFO: IP 10.0.1.65 not assigned to running interface
> stderr: Nov 09 02:40:44 INFO: EC2: Adjusting routing table and locally configuring IP address
> stderr: Nov 09 02:40:46 INFO: monitor: check routing table (API call) - rtb-01b4ea1ae0ec0a4d9
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 (resource-agents bug fix and enhancement update), 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/RHBA-2021:1736
Description of problem: The aws-vpc-move-ip resource agent's normal start operation throws errors that may lead users to think there was a problem. stderr: RTNETLINK answers: Cannot assign requested address stderr: Nov 09 02:38:24 WARNING: command failed, rc 2 These errors come from the ec2ip_drop() function. The start function calls ec2ip_get_and_configure(), which in turn calls ec2ip_drop() to delete the IP address immediately before adding it again. The errors shown above are thrown when the ec2ip_drop() runs `ip addr delete` against the managed IP address, which is not yet assigned. ~~~ ec2ip_drop() { cmd="ip addr delete ${OCF_RESKEY_ip}/32 dev $OCF_RESKEY_interface" ocf_log debug "executing command: $cmd" $cmd rc=$? if [ "$rc" -gt 0 ]; then ocf_log warn "command failed, rc $rc" return $OCF_ERR_GENERIC fi ~~~ Under normal circumstances, this command will always fail during the start operation. We have three valid options here: 1) Print the stdout and stderr from `ip addr delete` at only a debug level for the start operation. 2) Do not print the stdout and stderr from the ec2ip_drop() function at all for the start operation. 3) Remove the ec2ip_drop() call from the ec2ip_get_and_configure() function. - The ec2ip_get_and_configure() function should only be called when the IP address is **not** already assigned and up. - The ec2ip_get_and_configure() function calls ec2ip_drop() to delete the IP address and then immediately re-adds it. I favor option #1 just in case of unforeseen edge cases. ----- Version-Release number of selected component (if applicable): resource-agents-4.1.1-68.el8.x86_64 master ----- How reproducible: Always ----- Steps to Reproduce: 1. Create an aws-vpc-move-ip resource in disabled state. 2. Attempt to debug-start the resource (or enable it and check the logs). ----- Actual results: Operation start for aws-vip (ocf:heartbeat:aws-vpc-move-ip) returned: 'ok' (0) > stderr: Nov 09 02:38:20 INFO: EC2: Moving IP address 10.0.1.65 to this host by adjusting routing table rtb-01b4ea1ae0ec0a4d9 > stderr: Nov 09 02:38:20 INFO: monitor: check routing table (API call) - rtb-01b4ea1ae0ec0a4d9 > stderr: Nov 09 02:38:22 WARNING: IP 10.0.1.65 not assigned to running interface > stderr: Nov 09 02:38:22 INFO: EC2: Adjusting routing table and locally configuring IP address > stderr: RTNETLINK answers: Cannot assign requested address > stderr: Nov 09 02:38:24 WARNING: command failed, rc 2 > stderr: Nov 09 02:38:24 INFO: monitor: check routing table (API call) - rtb-01b4ea1ae0ec0a4d9 ----- Expected results: Operation start for aws-vip (ocf:heartbeat:aws-vpc-move-ip) returned: 'ok' (0) > stderr: Nov 09 02:40:43 INFO: EC2: Moving IP address 10.0.1.65 to this host by adjusting routing table rtb-01b4ea1ae0ec0a4d9 > stderr: Nov 09 02:40:43 INFO: monitor: check routing table (API call) - rtb-01b4ea1ae0ec0a4d9 > stderr: Nov 09 02:40:44 INFO: IP 10.0.1.65 not assigned to running interface > stderr: Nov 09 02:40:44 INFO: EC2: Adjusting routing table and locally configuring IP address > stderr: Nov 09 02:40:46 INFO: monitor: check routing table (API call) - rtb-01b4ea1ae0ec0a4d9