Bug 1732182
Summary: | [DOCS] crio.service does not start when there is no default route | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Eric Rich <erich> |
Component: | Documentation | Assignee: | Kathryn Alexander <kalexand> |
Status: | CLOSED EOL | QA Contact: | Johnny Liu <jialiu> |
Severity: | medium | Docs Contact: | Vikram Goyal <vigoyal> |
Priority: | medium | ||
Version: | 4.1.0 | CC: | aos-bugs, gblomqui, jokerman, mmccomas, pthomas, scuppett |
Target Milestone: | --- | ||
Target Release: | 4.2.z | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-05-18 06:55:48 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Currently, crio uses the default route to determine the "primary IP" for the node. It uses the IP address in the same subnet as the default route to determine this. However, I think the default route should really only be used as a hint to resolve abiguity in the case of multiple IPs. It a single IP case i.e. common case, it is trivial to determine the primary IP. 1.14 https://github.com/cri-o/cri-o/pull/2663 1.15 https://github.com/cri-o/cri-o/pull/2664 master https://github.com/cri-o/cri-o/pull/2662 Just got a change to test; doesn't seem to work https://github.com/cri-o/cri-o/pull/2662#issuecomment-516178852 While testing our fix for this, I discovered that the kube-apiserver also can't start if there is no default route. This will not be fixed in time for 4.2. In fact, I'm less convinced that it is something we should "fix" now that I see the upstream kube components have the same limitation. Disconnected and proxy documentation should indicate that a default route is required on nodes, even if that route can not reach the internet. |
Description of problem: > Jul 22 20:35:42 localhost.localdomain systemd[1]: Starting Open Container Initiative Daemon... > Jul 22 20:35:42 localhost.localdomain crio[10396]: time="2019-07-22 20:35:42.483075415Z" level=fatal msg="no default routes found in "/proc/net/route" or "/proc/net/ipv6_route"" > Jul 22 20:35:42 localhost.localdomain systemd[1]: crio.service: Main process exited, code=exited, status=1/FAILURE > Jul 22 20:35:42 localhost.localdomain systemd[1]: crio.service: Failed with result 'exit-code'. > Jul 22 20:35:42 localhost.localdomain systemd[1]: Failed to start Open Container Initiative Daemon. Version-Release number of selected component (if applicable): 4.1.6 How reproducible: 100% Steps to Reproduce: 1. Create an isolated network 2. Complete a bare metal install Actual results: The bootstrap process fails; because cri-o never starts. Expected results: Cri-o should be able to start on a system without a default route. Additional info: