New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1867392: Fixes multiple NICs OVN/OVS config #1999
Bug 1867392: Fixes multiple NICs OVN/OVS config #1999
Conversation
Deploying with multiple NICs will end up placing all NICs on the same default NM connection. If one of these interfaces fails to DHCP or does not DHCP in time during boot, NM-wait-online will fail (even though 1 NIC may have DHCP'ed correctly). Therefore the ovs-configuration service should not require NM-wait-online, but we should wait until it is completed and we do want it. However, if it fails we still try to to check the system if a default gateway is present. Additionally, since multiple NICs may share the same NM connection, we cannot always just bring it down. Instead, change the behavior to just disconnect the NIC and then bring up the higher priority connection later to preserve the default NM connection. Signed-off-by: Tim Rozet <trozet@redhat.com>
@trozet: This pull request references Bugzilla bug 1867392, which is invalid:
Comment In 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. |
/bugzilla refresh |
@trozet: This pull request references Bugzilla bug 1867392, 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
In 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. |
@danwinship PTAL got confirmation it fixed the reporter's issue |
yep, I can attest this PR solved the issue in our BM environment. |
/lgtm |
/assign @yuqi-zhang |
/assign @kikisdeliveryservice |
/retest |
1 similar comment
/retest |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danwinship, kikisdeliveryservice, trozet The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
@trozet: The following tests failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
@trozet: All pull requests linked via external trackers have merged: openshift/machine-config-operator#1999. Bugzilla bug 1867392 has been moved to the MODIFIED state. In 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. |
Deploying with multiple NICs will end up placing all NICs on the same
default NM connection. If one of these interfaces fails to DHCP or does
not DHCP in time during boot, NM-wait-online will fail (even though 1
NIC may have DHCP'ed correctly). Therefore the ovs-configuration service
should not require NM-wait-online, but we should wait until it is
completed and we do want it. However, if it fails we still try to to
check the system if a default gateway is present.
Additionally, since multiple NICs may share the same NM connection, we
cannot always just bring it down. Instead, change the behavior to just
disconnect the NIC and then bring up the higher priority connection
later to preserve the default NM connection.
Signed-off-by: Tim Rozet trozet@redhat.com