Change:
func UsingLegacyCadvisorStats(runtime, runtimeEndpoint string) bool { return runtime == kubetypes.RktContainerRuntime || (runtime == kubetypes.DockerContainerRuntime && goruntime.GOOS == "linux") || <del> runtimeEndpoint == "/var/run/crio.sock" </del> <ins> runtimeEndpoint == CrioSocket </ins> }

Discussion:
BUG REPORT While configuring the kubelet with: And having the sock file on that location (default location from cri), the following error occurs: Later line: Uses the correct socket. Result: Disruptive in understanding other failures. Containers still start. Environment: Kubernetes version: 1.8.0-5, 1.9.0-beta.2 Cloud provider: gce OS: Ubuntu 16.04 Kernel (e.g. ): Linux kubeworker01 4.10.0-42-generic ~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: The hard way Others: Full kubelet config (as of now): Internal log reference: syslog.v6.3
/area [kubelet] /sig [node]
/area kubelet /sig node /assign
This is because uses , while is using as default. We should make them consistent. Fixed in . PTAL.
What are the consequences? Is it more than cosmetical? Does it affect the usage of CRI-O in 1.9.0 or how does it affect users?
/assign Is this relevant for CRI-O in 1.9.0?
It (at this moment) mostly looks cosmetical, however when I add a cloud provider (--cloud-provider=gce in this case) to the kubelet config, the whole thing breaks consistently on PLEG. I am trying to figure out if there is a relation between that and the
Can you weigh in on whether this is a release-blocker for 1.9.0?
Tentatively adding milestone so we can track getting a judgement from sig-node.
-- i think this is fixed in the packaging, let me close with and
fixed in packaging yeah, from 1.8 we moved to "" so you need to start kubelet with that socket path
Discussed at sig-node earlier today, and this is not a release blocker. Also like mentioned above, the issue was fixed in the packaging.
There is a reference that needs to be fixed for the new socket location. The referenced pr is required to ensure stats summary endpoint understands the right location, and this keeps it consistent with cadvisor after its rebase in 1.9.

/priority critical-urgent /kind bug /sig node /status approved-for-milestone
/status in-progress
[MILESTONENOTIFIER] Milestone Issue Current Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Hi, I am hitting the same error in this thread on my Openshift4.2 cluster which has configured CRIO on the kubelet. I would like to hit to get inventory of the containers. Any body has any insights why I am hitting this error when I make curl calls from the k8s node which has configured for the CRIO? [root /]# curl -v --unix-socket http://localhost/info Trying Immediate connect fail for No such file or directory Closing connection 0 curl: (7) Couldn't connect to server [root /]# sshadmin kubectl version Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-01-14T21:04:32Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.6+", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-01-17T17:43:42Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"