Bug 2047445: Filter out empty lines and link-local addrs from nmcli output - #2933
Bug 2047445: Filter out empty lines and link-local addrs from nmcli output#2933cybertron wants to merge 1 commit into
Conversation
For some reason the nmcli call to determine the number of ipv6 addresses on an interface is sometimes returning a blank line as part of the output. This causes a single address to look like 2 because we're just checking the line count and makes us incorrectly set "ipv6.may-fail no" on the interface. This causes the connection to fail and prevents ovs-configuration from completing. Here's some example output from an affected system: [root@master-0-0 core]# nmcli -m multiline --get-values ip6.address conn show 84a523ff-ee8a-4a29-94ca-47590eb0cb76 IP6.ADDRESS[1]:fe80::5054:ff:fe6e:6923/64 [root@master-0-0 core]# Additionally, we have seen another case where the link-local address from both the baremetal and provisioning networks shows up in the output of this command. That will also fail because we're just looking for line count > 1. This change alters the logic to filter out blank lines and any link-local addresses, then sees if anything is left. This should be less prone to false positive results.
openshift-ci
Bot
added
the
bugzilla/severity-urgent
|
@cybertron: This pull request references Bugzilla bug 2047445, which is invalid:
Comment DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
openshift-ci
Bot
added
the
bugzilla/invalid-bug
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: cybertron The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/bugzilla refresh |
|
@cybertron: This pull request references Bugzilla bug 2047445, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
Requesting review from QA contact: DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
openshift-ci
Bot
added
bugzilla/valid-bug
|
/test e2e-metal-ipi-ovn-dualstack |
|
@cybertron: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
We've decided to go with #2934 instead. |
|
@cybertron: This pull request references Bugzilla bug 2047445. The bug has been updated to no longer refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
1 participant
For some reason the nmcli call to determine the number of ipv6
addresses on an interface is sometimes returning a blank line as
part of the output. This causes a single address to look like 2
because we're just checking the line count and makes us incorrectly
set "ipv6.may-fail no" on the interface. This causes the connection
to fail and prevents ovs-configuration from completing.
Here's some example output from an affected system:
[root@master-0-0 core]# nmcli -m multiline --get-values ip6.address conn show 84a523ff-ee8a-4a29-94ca-47590eb0cb76
IP6.ADDRESS[1]:fe80::5054:ff:fe6e:6923/64
[root@master-0-0 core]#
Additionally, we have seen another case where the link-local address
from both the baremetal and provisioning networks shows up in the
output of this command. That will also fail because we're just
looking for line count > 1.
This change alters the logic to filter out blank lines and any
link-local addresses, then sees if anything is left. This should be
less prone to false positive results.
- What I did
- How to verify it
- Description for the changelog