-
Notifications
You must be signed in to change notification settings - Fork 40
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
OCPBUGS-32141: Handle scenario when VIP does not belong to L2 #313
Conversation
Lately we were made aware that the current logic of maching interfaces to VIPs is broken in vSphere IPI scenarios when VIP does not belong to Machine Network. Usually such a combination would be forbidden, but for vSphere it is allowed. As a result, we may have e.g. an interface 10.8.38.29, machine network 10.8.42.0/23 and VIP 10.8.0.83. As counterintuitively it looks for baremetal, with vSphere it is allowed. This PR fixes the logic we introduced in January 2023 where we added a hard-check to make sure VIP belongs to a subnet of the NIC. With this new logic, if the scenario described above happens, we will fallback to the logic from years ago when we were simply choosing a NodeInternalIP of the matching IP stack. Closes: OCPBUGS-32141
@mkowalski: This pull request references Jira Issue OCPBUGS-32141, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. 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 openshift-eng/jira-lifecycle-plugin repository. |
@mkowalski: once the present PR merges, I will cherry-pick it on top of release-4.15,release-4.14 in a new PR and assign it to you. 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-sigs/prow repository. |
/jira refresh |
@mkowalski: This pull request references Jira Issue OCPBUGS-32141, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
Requesting review from QA contact: 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 openshift-eng/jira-lifecycle-plugin repository. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cybertron, mkowalski 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 |
/jira refresh The requirements for Jira bugs have changed (Jira issues linked to PRs on main branch need to target different OCP), recalculating validity. |
@openshift-bot: This pull request references Jira Issue OCPBUGS-32141, which is valid. 3 validation(s) were run on this bug
Requesting review from QA contact: 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 openshift-eng/jira-lifecycle-plugin repository. |
/jira refresh The requirements for Jira bugs have changed (Jira issues linked to PRs on main branch need to target different OCP), recalculating validity. |
@openshift-bot: This pull request references Jira Issue OCPBUGS-32141, 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 openshift-eng/jira-lifecycle-plugin repository. |
/jira refresh This is a fix for a common use case on vsphere that is now being found in the field. We can't wait for 4.16 to ship before we get it in. |
@cybertron: This pull request references Jira Issue OCPBUGS-32141, which is valid. 3 validation(s) were run on this bug
Requesting review from QA contact: 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 openshift-eng/jira-lifecycle-plugin repository. |
@mkowalski: all tests passed! 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-sigs/prow repository. I understand the commands that are listed here. |
@mkowalski: Jira Issue OCPBUGS-32141: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-32141 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 openshift-eng/jira-lifecycle-plugin repository. |
[ART PR BUILD NOTIFIER] This PR has been included in build ose-baremetal-runtimecfg-container-v4.17.0-202405210211.p0.gbc72f01.assembly.stream.el9 for distgit baremetal-runtimecfg. |
…for ingress) In openshift#313 we have fixed logic for topologies where VIP does not belong to the L2 of the node. But this change was missing additional part of the code that had the same flaw, i.e. generation of ingress config. This PR is replicating the fix openshift#313. Fixes: OCPBUGS-32141
In openshift#313 we have fixed some logic regarding to VIPs in ELB scenario, but we forgot to handle the error. Because of this, even if we detected the IP correctly, the function could stil return a non-empty error causing the installation to fail. This PR contains a simple fix to return `nil` instead of `err` in case we managed to recover from the issue. Fixes: OCPBUGS-32141
…for ingress) In openshift#313 we have fixed logic for topologies where VIP does not belong to the L2 of the node. But this change was missing additional part of the code that had the same flaw, i.e. generation of ingress config. This PR is replicating the fix openshift#313. Fixes: OCPBUGS-32141
Lately we were made aware that the current logic of maching interfaces to VIPs is broken in vSphere IPI scenarios when VIP does not belong to Machine Network. Usually such a combination would be forbidden, but for vSphere it is allowed.
As a result, we may have e.g. an interface 10.8.38.29, machine network 10.8.42.0/23 and VIP 10.8.0.83. As counterintuitively it looks for baremetal, with vSphere it is allowed.
This PR fixes the logic we introduced in January 2023 where we added a hard-check to make sure VIP belongs to a subnet of the NIC. With this new logic, if the scenario described above happens, we will fallback to the logic from years ago when we were simply choosing a NodeInternalIP of the matching IP stack.
Closes: OCPBUGS-32141