Bug 2040671: Fix the way the network stack is determined #239
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
/test e2e-metal-ipi-ovn-dualstack |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sadasu 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 |
openshift-ci
bot
added
the
approved
|
The cluster failed to build because of errors with the authentication and console operators. |
|
It's still passing |
sadasu
changed the title
openshift-ci
bot
added
bugzilla/severity-urgent
|
@sadasu: This pull request references Bugzilla bug 2040671, 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
No GitHub users were found matching the public email listed for the QA contact in Bugzilla (augol@redhat.com), skipping review request. 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. |
|
Looks like -metal-ipi-ovn-dualstack is failing because only 1 internal IP is defined STEP: Destroying namespace "e2e-dualstack-497" for this suite. failed: (3.5s) 2022-01-20T20:07:15 "[sig-network] [Feature:IPv6DualStack] should have ipv4 and ipv6 internal node ip [Suite:openshift/conformance/parallel] [Suite:k8s]" |
sadasu
force-pushed
the
sadasu-2040671
branch
2 times, most recently
from
5ad7a59
to
b6fb52a
Compare
|
/test e2e-metal-ipi-ovn-dualstack |
|
/retest |
|
Even if this doesn't work it should make what we're trying to do explicit, instead of the previous code that was highly misleading about what would actually happen. |
openshift-ci
bot
added
the
do-not-merge/hold
|
We were looking at apiServerInternalURI and apiServerURL fields in the Infrastructure CR to figure out if the installation was a dualstack one. The problem with that approach was that these two URLs always had only one IP associated with them even in dualstack scenarios. That resulted in CBO passing the wrong IP_OPTIONS to metal3 containers. With this revised approach, we are looking at the ServiceNetwork in the Network CR . In dualstack installs, the ServiceNetwork is expected to have 2 sets of IPs one for IPv4 and the other for IPv6. |
This would be good info for the commit message :) |
|
@sadasu: This pull request references Bugzilla bug 2040671, which is valid. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Bugzilla (augol@redhat.com), skipping review request. 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. |
|
/lgtm For some reason it looks like the dual stack job is still passing ip=dhcp to the nodes, but I agree that this looks like a step in the right direction. |
|
/test e2e-metal-ipi-serial-ipv4 |
|
/test e2e-metal-ipi-ovn-ipv6 |
|
Latest ipv6 failure is not related to this job; /test e2e-metal-ipi-ovn-ipv6 |
I don't see that on the workers. I see it passing I do see that on the control plane, because obviously this change doesn't affect the installer. However, none of the worker Nodes came up with an IPv6 address, so I suspect we will need to use |
sadasu
force-pushed
the
sadasu-2040671
branch
from
b6fb52a
to
e4248af
Compare
|
/test e2e-metal-ipi-ovn-dualstack |
|
/test e2e-agnostic current failures don't seem related to current changes |
|
/test e2e-metal-ipi |
|
/retest |
|
/lgtm |
|
/retest |
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
/override ci/prow/e2e-metal-ipi-ovn-dualstack |
|
@sadasu: Overrode contexts on behalf of sadasu: ci/prow/e2e-metal-ipi-ovn-dualstack 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. |
|
/retest |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
|
@sadasu: Some pull requests linked via external trackers have merged: The following pull requests linked via external trackers have not merged: These pull request must merge or be unlinked from the Bugzilla bug in order for it to move to the next state. Once unlinked, request a bug refresh with Bugzilla bug 2040671 has not 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. |
|
@sadasu: 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/test-infra repository. I understand the commands that are listed here. |
We were looking at apiServerInternalURI and apiServerURL fields in the Infrastructure CR to figure out if the installation was a dualstack one. The problem with that approach was that these two URLs always had only one IP associated with them even in dualstack scenarios. That resulted in CBO passing the wrong IP_OPTIONS to metal3 containers.
With this revised approach, we are looking at the ServiceNetwork in the Network CR . In dualstack installs, the ServiceNetwork is expected to have 2 sets of IPs one for IPv4 and the other for IPv6.