daemonBinary seems to be always empty when getting image from Daemon?

[dinever]

Hi,

It looks like the variable daemonBinary was never set before getting the image from the daemon:

minikube/pkg/minikube/image/image.go

Line 53 in 807440a

var daemonBinary string

minikube/pkg/minikube/image/image.go

Line 384 in 807440a

img, err = retrieveDaemon(daemonBinary, ref)

Therefore, images will always be pulled from the registry instead.

The only place where the variable is set is in

minikube/pkg/minikube/image/image.go

Lines 101 to 109 in 807440a

	func DigestByGoLib(binary, imgName string) string {
	ref, err := name.ParseReference(imgName, name.WeakValidation)
	if err != nil {
	klog.Infof("error parsing image name %s ref %v ", imgName, err)
	return ""
	}
	daemonBinary = binary
	img, _, err := retrieveImage(ref, imgName)

Which only happens when loading an already cached image

Steps to reproduce the issue:

1. Apply the following patch

diff --git a/pkg/minikube/image/image.go b/pkg/minikube/image/image.go
index e3a91b4ac..76d5b0322 100644
--- a/pkg/minikube/image/image.go
+++ b/pkg/minikube/image/image.go
@@ -381,6 +381,7 @@ func retrieveImage(ref name.Reference, imgName string) (v1.Image, string, error)
                                klog.Infof("short name: %s", imgName)
                        }
                }
+               klog.Infof("daemon binary: %s", daemonBinary)
                img, err = retrieveDaemon(daemonBinary, ref)
                if err == nil {
                        return img, imgName, nil

2. Clear all cache
3. docker pull busybox:latest
4. make
5. minikube start
6. minikube --log_file=./loadImage.log image load busybox:latest
7. When minikube trys to get the image from the daemon, we will see that daemonBinary is always an empty string:

I0509 22:56:33.800534  125589 image.go:384] daemon binary: 

If this is a bug, I can submit a PR to fix it. But not sure how to handle multiple profiles. For example, what if the user has two clusters, one using Docker and the other using Podman? Should we just try both daemons and see which one gets the image for us?

Thanks!

Full output of minikube logs command:

klog:

Log file created at: 2021/05/09 22:56:33
Running on machine: dinever-Z490-VISION-D
Binary: Built with gc go1.15.7 for linux/amd64
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
I0509 22:56:33.614812  125589 out.go:291] Setting OutFile to fd 1 ...
I0509 22:56:33.614898  125589 out.go:343] isatty.IsTerminal(1) = true
I0509 22:56:33.614900  125589 out.go:304] Setting ErrFile to fd 2...
I0509 22:56:33.614902  125589 out.go:343] isatty.IsTerminal(2) = true
I0509 22:56:33.614954  125589 root.go:316] Updating PATH: /home/dinever/.minikube/bin
I0509 22:56:33.615258  125589 cache.go:108] acquiring lock: {Name:mke630cad17755c8fc78faa5507b8ce4b1a83066 Clock:{} Delay:500ms Timeout:10m0s Cancel:<nil>}
I0509 22:56:33.615368  125589 image.go:367] retrieving image: busybox:latest
I0509 22:56:33.615373  125589 image.go:373] checking repository: index.docker.io/library/busybox
I0509 22:56:33.800531  125589 image.go:377] canonical name: docker.io/library/busybox:latest
I0509 22:56:33.800534  125589 image.go:384] daemon binary:
I0509 22:56:34.073852  125589 cache.go:162] opening:  /home/dinever/.minikube/cache/images/busybox_latest
I0509 22:56:34.156002  125589 cache.go:157] /home/dinever/.minikube/cache/images/busybox_latest exists
I0509 22:56:34.156017  125589 cache.go:97] cache image "busybox:latest" -> "/home/dinever/.minikube/cache/images/busybox_latest" took 540.763189ms
I0509 22:56:34.156027  125589 cache.go:81] save to tar file busybox:latest -> /home/dinever/.minikube/cache/images/busybox_latest succeeded
I0509 22:56:34.156033  125589 cache.go:88] Successfully saved all images to host disk.
I0509 22:56:34.156372  125589 cli_runner.go:115] Run: docker container inspect minikube --format={{.State.Status}}
I0509 22:56:34.176562  125589 ssh_runner.go:149] Run: systemctl --version
I0509 22:56:34.176592  125589 cli_runner.go:115] Run: docker container inspect -f "'{{(index (index .NetworkSettings.Ports "22/tcp") 0).HostPort}}'" minikube
I0509 22:56:34.196504  125589 sshutil.go:53] new ssh client: &{IP:127.0.0.1 Port:49167 SSHKeyPath:/home/dinever/.minikube/machines/minikube/id_rsa Username:docker}
I0509 22:56:34.270178  125589 ssh_runner.go:149] Run: docker images --format {{.Repository}}:{{.Tag}}
I0509 22:56:34.290498  125589 docker.go:528] Got preloaded images: -- stdout --
busybox:latest
gcr.io/k8s-minikube/storage-provisioner:v5
k8s.gcr.io/kube-proxy:v1.20.2
k8s.gcr.io/kube-apiserver:v1.20.2
k8s.gcr.io/kube-controller-manager:v1.20.2
k8s.gcr.io/kube-scheduler:v1.20.2
kubernetesui/dashboard:v2.1.0
k8s.gcr.io/etcd:3.4.13-0
k8s.gcr.io/coredns:1.7.0
kubernetesui/metrics-scraper:v1.0.4
k8s.gcr.io/pause:3.2

-- /stdout --
I0509 22:56:34.290505  125589 cache_images.go:74] Images are preloaded, skipping loading
I0509 22:56:34.290509  125589 cache_images.go:261] succeeded pushing to: minikube
I0509 22:56:34.290511  125589 cache_images.go:262] failed pushing to:

Full output of failed command:

[afbjorklund]

Yes, this was related to the issues with the LoadImage test failing. We will revert that PR for now. #11356

[afbjorklund]

But not sure how to handle multiple profiles. For example, what if the user has two clusters, one using Docker and the other using Podman? Should we just try both daemons and see which one gets the image for us?

The code was trying use docker for the docker driver and podman for the podman driver. (which failed)

Ultimately it might even need something like daemon:// och podman:// like some other tools are doing.

https://github.com/GoogleContainerTools/container-diff#image-sources

And probably have to use qualified names, for images that use docker.io

It's about #11059 really