Bug 2096226: Check chosen node-ip can be used #181
Conversation
derekhiggins
changed the title
openshift-ci
bot
added
bugzilla/severity-unspecified
|
@derekhiggins: This pull request references Bugzilla bug 2096226, 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. |
derekhiggins
force-pushed
the
check-tentative
branch
from
1037b0c
to
0a24945
Compare
cmd/runtimecfg/node-ip.go
Outdated
| // If using IPv6, verify that the choosen address isn't tentative | ||
| // i.e. we can actually bind to it | ||
| if net.IPv6len == len(chosen[0]) { | ||
| _, err := net.Listen("tcp", "["+chosen[0].String()+"]:10010") |
There was a problem hiding this comment.
Binding to a hard-coded port seems a little hacky - although we know that the way things are deployed on startup this should run prior to crio.service, this would fail if someone runs the node-ip check manually after it's running, right?
I'm wondering if we should either use a random high port, or ideally check the connection flags e.g can we determine if the state is/isn't tentative via the golang rtnetlink bindings?
https://pkg.go.dev/github.com/vishvananda/go-netlink/rtnetlink/addr#Flags
There was a problem hiding this comment.
I can remove the port number and a random on is used, I didn't do this as it may pick a port another service wants, but its so short lived I guess it should be ok
I can Look into checking the flags
In IPv6, if the chosen IP address is still tentative then it can't be bound to, resulting in crio crashing. Check that the IP address can be used and if not fail or retry as appropriate.
derekhiggins
force-pushed
the
check-tentative
branch
from
0a24945
to
5649117
Compare
|
lgtm pending ipv6 job pass Note that it is important for this to work after crio has already started because the node-ip logic is also used in the resolv-prepender script that makes sure our local DNS server is first in resolv.conf. I'm a little confused how the ipv6 job passed on the previous version of this. |
openshift-ci
bot
added
bugzilla/severity-high
|
@cybertron: This pull request references Bugzilla bug 2096226, 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 (vvoronko@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. |
|
@derekhiggins: 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. |
|
/lgtm Looks like this will unblock ipv6 ci and it's not an unreasonable thing to check, so let's go with it. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cybertron, derekhiggins 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
|
@derekhiggins: All pull requests linked via external trackers have merged: Bugzilla bug 2096226 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. |
In openshift#181 we fixed a problem where ipv6 addresses are initially in a state that is not usable by services. However, this was only done for the code path where VIPs are in use, so it only applies to IPI deployments that are not using remote workers. It turns out this is also happening on non-IPI deployments (and likely for IPI deployments with remote workers), so we need to run the same check on that code path.
In openshift#181 we fixed a problem where ipv6 addresses are initially in a state that is not usable by services. However, this was only done for the code path where VIPs are in use, so it only applies to IPI deployments that are not using remote workers. It turns out this is also happening on non-IPI deployments (and likely for IPI deployments with remote workers), so we need to run the same check on that code path.
In openshift#181 we fixed a problem where ipv6 addresses are initially in a state that is not usable by services. However, this was only done for the code path where VIPs are in use, so it only applies to IPI deployments that are not using remote workers. It turns out this is also happening on non-IPI deployments (and likely for IPI deployments with remote workers), so we need to run the same check on that code path. (cherry picked from commit 998bbd4)
In openshift#181 we fixed a problem where ipv6 addresses are initially in a state that is not usable by services. However, this was only done for the code path where VIPs are in use, so it only applies to IPI deployments that are not using remote workers. It turns out this is also happening on non-IPI deployments (and likely for IPI deployments with remote workers), so we need to run the same check on that code path.
In openshift#181 we fixed a problem where ipv6 addresses are initially in a state that is not usable by services. However, this was only done for the code path where VIPs are in use, so it only applies to IPI deployments that are not using remote workers. It turns out this is also happening on non-IPI deployments (and likely for IPI deployments with remote workers), so we need to run the same check on that code path.
In IPv6, if the chosen IP address is still tentative
then it can't be bound to, resulting in crio crashing.
Check that the IP address can be used and if not fail
or retry as appropriate.