Loading kicbase from cache to daemon outputs confusing loading progress

[nagnampalli]

What Happened?

😄 minikube v1.25.1 on Darwin 11.6
✨ Automatically selected the docker driver. Other choices: virtualbox, ssh
👍 Starting control plane node minikube in cluster minikube
🚜 Pulling base image ...
> gcr.io/k8s-minikube/kicbase: 0 B [] ?% ? p/s ?
> gcr.io/k8s-minikube/kicbase: 0 B [] ?% ? p/s ?

Attach the log file

😄 minikube v1.25.1 on Darwin 11.6
✨ Automatically selected the docker driver. Other choices: virtualbox, ssh
👍 Starting control plane node minikube in cluster minikube
🚜 Pulling base image ...
> gcr.io/k8s-minikube/kicbase: 0 B [] ?% ? p/s ?
> gcr.io/k8s-minikube/kicbase: 0 B [] ?% ? p/s ?

Operating System

macOS (Default)

Driver

Docker

[RA489]

/kind support

[siikanen]

Same issue here. Seems like there has been issues with minikube when it tries to connect to gcr.io. However seems the issue fixes itself by just waiting along

[floka94]

Same issue here :-(

[sharifelgamal]

Yeah this definitely strikes me as a connectivity issue. Do you end up getting a timeout or does it eventually resolve itself?

[siikanen]

Usually just restarting minikube (or deleting it) couple of times fixes it. Defeneitly something related to minikube/docker(?) because other applications seem to be functioning fine

[ckarageorgkaneen]

I had the same issue with minikube v1.24.0. It was fixed after upgrading to v1.25.0. OS: Ubuntu 20.10

[spowelljr]

@nagnampalli @siikanen @floka94 Can any of you confirm if updating to minikube v1.25.0 resolves this issue?

[ZCJ]

@spowelljr I am on 1.26.0 and recently started seeing this issue

[spowelljr]

Thanks for the confirmation @ZCJ. I just discovered that this occurs when you have the kicbase image stored in your minikube home folder cache, but it's not loaded into Docker, so it's copying the image from your file system into Docker.

This will likely occur if you clean out docker using docker system prune.

I'm assuming there's no % being shown because it's not a network activity, it's just writing the tarbar into the daemon and I'm assuming we don't get feedback on what the completion progress is.

I think the next steps are:

1. Check to see if there is a way to get progress back from the command doing the copy
2. If not, we should change this to use the loading circles used for Creating docker container & Preparing Kubernetes

[hemanthkotaprolu]

Somebody help me here please!Did anyone able to get pass through this issue. Thanks

[spowelljr]

@hemanthkotaprolu it usually takes around 50 seconds for me, did it end up completing?

[afbjorklund]

@spowelljr Currently the hack done by go-containerregistry only has network progress (and doesn't support podman)

https://github.com/google/go-containerregistry/blob/main/pkg/v1/tarball/write.go ("docker save", with progress)

https://github.com/google/go-containerregistry/blob/main/pkg/v1/daemon/write.go ("docker load", without progress)

I'm not sure they will fix it, so one workaround is to call the docker and podman clients directly instead of using daemon

[Nelgit007]

Somebody help me here please!Did anyone able to get pass through this issue. Thanks

Yeah. If its on windows like mine. You just have to wait a bit longer for it to begin pulling the image. 5 to 10min

[hemanthkotaprolu]

@hemanthkotaprolu it usually takes around 50 seconds for me, did it end up completing?

Thanks @spowelljr . After sometime it got worked. Thanks,

[emreigrek]

took 2mins for me, thank you

[Elias-Yona]

took 2mins for me, thank you

20 mins for me. I almost deleted minikube.

[spowelljr]

This is fixed by #15528

The problem is it was downloading the kicbase image twice.