-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
none driver: look for cri-dockerd instead of hardcoding #15784
Conversation
pkg/minikube/cruntime/docker.go
Outdated
@@ -688,6 +688,14 @@ const ( | |||
CNICacheDir = "/var/lib/cni/cache" | |||
) | |||
|
|||
func getCriDockerdPath(cr CommandRunner) string { | |||
rr, err := cr.RunCmd(exec.Command("which", "cri-dockerd")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which
is not a standard command, and parsing its output is dangerous at best. The stdlib os.LookPath
is designed for this use-case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you run LookPath over ssh ? We could run command -v
, at least for the recently modern ones
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, command -v
is at least POSIX. I suppose the remote use-case makes this harder; but at the same time it feels very impure. The ability to go run
over SSH might be nice in the end, but that's a lot of machinery to build out.
Does it make sense to abstract this a layer deeper and write a cr.LookPath
that uses the external binary or os.LookPath
based on the target?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but that is more of a separate refactor
pkg/minikube/cruntime/docker.go
Outdated
func getCriDockerdPath(cr CommandRunner) string { | ||
rr, err := cr.RunCmd(exec.Command("which", "cri-dockerd")) | ||
if err != nil { | ||
return "/usr/bin/cri-dockerd" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably better to return an error/fail early, where we can describe what happened, rather than fail later in the systemd unit...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we already looked for cri-dockerd
in the user-facing command code, so this is not supposed to fail (at all)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, it seems better for everyone's collective sanity that an error is returned here, and that it does tear down the call stack/bubble up, as otherwise if the prelude to this code being invoked changes (and these assumptions are not obvious), severe bit-rot/surprising effects could ensue...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it was not worse (than before)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@afbjorklund how about returning the current default value in case of "which" failing,
currently it assumes "/usr/bin/cri-dockerd" in case "which" fails we dont even try the old way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is the default.
Some people install the daemon in /usr/local/bin, rather than under /usr/bin as the unit expects.
177bb88
to
90bc8a9
Compare
/ok-to-test |
kvm2 driver with docker runtime
Times for minikube start: 53.6s 54.8s 52.2s 53.3s 53.9s Times for minikube (PR 15784) ingress: 28.2s 25.3s 27.7s 24.7s 26.3s docker driver with docker runtime
Times for minikube start: 25.7s 26.1s 26.0s 26.6s 27.2s Times for minikube ingress: 49.6s 50.6s 25.1s 22.1s 19.1s docker driver with containerd runtime
Times for minikube start: 21.0s 23.1s 22.0s 22.2s 22.0s Times for minikube ingress: 32.6s 31.6s 20.6s 32.6s 32.6s |
These are the flake rates of all failed tests.
To see the flake rates of all tests by environment, click here. |
Is it possible that what you look for with |
The current minikube code creates a |
There is a possibility of such, especially as the user (and not minikube) controls who you execute as and thus the content of the remote |
Note that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@afbjorklund sorry I changed my review
@neersighted Thanks for your reply. I've only used minikube with the none driver, so I don't really understand how it works with other drivers, but my understanding is that if cri-docker.service doesn't work, minikube won't work either. right? |
The issue here is that cri-dockerd.service does work. Then minikube attempts to change the command line to set the CNI, and we end up here. This PR represents an attempt to prevent minikube from having strong opinions about what path cri-dockerd is available at. |
@neersighted Thank you for your explanations! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afbjorklund, medyagh 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 |
Some people install the daemon in /usr/local/bin,
rather than under /usr/bin as the unit expects.
Closes #15265