Detect container runtime to choose to start scope
lilic opened this issue · comments
When the container runtime is not Docker, we need to pass the correct endpoint and flag to start scope with the correct CRI supported container runtime, for that we need to send the info to generate the correct manifest files and expose the socket in the volumes.
Right now finding out which container runtime the kubernetes cluster is using is not the easiest as that information is not exposed, but we can find out by:
- Grepping through the logs of kubelet or minikube. The problem with that is that those logs live in different places and sometimes we do not have access to them.
- Looking at the kubelet process and finding out which flag it was started with. The problem is when it comes to minikube for example or when we don't have access to that process.
- There is a way of mounting all the sockets in the launcher deployment file and creating a check to see to which on CRI connects to and getting the version and runtime information through CRI connection directly. Only problem is that the user can specify a custom path to the socket and we would need to guess.
- Create a flag with which the user passes their endpoint runtime, this is similar in how kubelet and other tools are started anyways so I think choosing this approach is not the worst.
I would suggest we try to guess on a best effort bases (trying with 3rd approach) and also add a flag (4th) to let the user override the runtime they use. At least as a temporary solution until this issue kubernetes/kubernetes#64460 exposes the container runtime information.
I would suggest we try to guess on a best effort bases (trying with 3rd approach)
I suggest some auto-detection along 3, that errors out if we cannot talk the docker/cri we have detected/guessed, with a clear message telling the user what went wrong and that they should specify the CRI socket path with the flag.
3+4 sounds good to me too!
What is happening with this? I thought we had some auto-detection in place already, do we not?
Yes it was added in #252 But until I confirm it works, I do not want to close this. Ran into small issues like we need to change all our image names to prefix them with the docker.io registry, etc. So it's still open until things work in dev. :)
ok. I would rather close this and have follow-up issues for breakages we find. That way it's easier to see what is left to do.
Closed in #252
Reopening as we had to disable this for now until a new version of scope is released which includes the CRI and the flag.
how is it going now?