Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect container runtime to choose to start scope #243

Open
lilic opened this issue Jul 27, 2018 · 8 comments
Open

Detect container runtime to choose to start scope #243

lilic opened this issue Jul 27, 2018 · 8 comments

Comments

@lilic
Copy link
Contributor

lilic commented Jul 27, 2018

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

cc @leth @dlespiau What do you think?

@rade
Copy link
Member

rade commented Jul 27, 2018

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.

@dlespiau
Copy link
Contributor

3+4 sounds good to me too!

@rade
Copy link
Member

rade commented Aug 14, 2018

What is happening with this? I thought we had some auto-detection in place already, do we not?

@lilic
Copy link
Contributor Author

lilic commented Aug 14, 2018

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. :)

@rade
Copy link
Member

rade commented Aug 14, 2018

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.

@lilic
Copy link
Contributor Author

lilic commented Aug 14, 2018

Closed in #252

@lilic lilic closed this as completed Aug 14, 2018
@lilic
Copy link
Contributor Author

lilic commented Aug 30, 2018

Reopening as we had to disable this for now until a new version of scope is released which includes the CRI and the flag.

#260

@lilic lilic reopened this Aug 30, 2018
@huapox
Copy link

huapox commented Apr 27, 2019

how is it going now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants