Bug 2047445: Use ip command to check for ipv6 addresses - #2934
Conversation
|
@cybertron: This pull request references Bugzilla bug 2047445, which is valid. 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. |
|
/test e2e-metal-ipi-ovn-dualstack |
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 modifies the check to use the ip command on the interface directly, so we should only get the addresses on the interface itself and we can use jq to filter out the ones we're not interested in. Although the bug specifically related to ipv6 addresses, in theory a similar issue could exist for ipv4 so that check is also converted.
649598d to
e19fcc4
Compare
|
/lgtm |
|
/test e2e-metal-ipi-ovn-dualstack |
|
/assign @kikisdeliveryservice |
|
/retest-required |
|
/retest-required |
|
(clearly this should be in a compiled language, not shell; hopefully we can do that at some point) /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, cybertron, jcaamano, trozet The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/bugzilla refresh The requirements for Bugzilla bugs have changed (BZs linked to PRs on master branch need to target OCP 4.11), recalculating validity. |
|
@openshift-bot: 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. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
14 similar comments
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/hold e2e-agnostic-upgrade is perma failing. @trozet @cybertron please investigate and see if this is because of this PR or if an override is needed. |
|
@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. |
|
@aravindhp looks like this job is perma fail across all PRs. The e2e-agnostic-upgrade uses openshift-sdn (not OVN), so the changes in this PR are never executed. The jobs that exercise this patch are: ci/prow/e2e-metal-ipi-ovn-dualstack — Job succeeded. |
|
/cherry-pick release-4.10 |
|
@vpickard: once the present PR merges, I will cherry-pick it on top of release-4.10 in a new PR and assign it to you. 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. |
|
As this PR is not exercised in the current e2e-agnostic-upgrade job, the severity of the underlying bug and the current permafail state of the upgrade, overriding on this PR to expedite the fix /override ci/prow/e2e-agnostic-upgrade |
|
@kikisdeliveryservice: Overrode contexts on behalf of kikisdeliveryservice: ci/prow/e2e-agnostic-upgrade 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. |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
@cybertron: All pull requests linked via external trackers have merged: Bugzilla bug 2047445 has been moved to the MODIFIED state. 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. |
|
@aravindhp: new pull request created: #2938 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. |
Bug 2047445: Use ip command to check for ipv6 addresses
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 modifies the check to use the ip command on the interface
directly (instead of the connection profile) so we should only get
the addresses on the interface, and we can filter out non-ipv6 ones
with jq. Hopefully this will be more robust than grepping and line
counting nmcli output.
- What I did
- How to verify it
- Description for the changelog