-
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
Load kicbase image from right cache and add log #11346
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afbjorklund 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 |
/ok-to-test |
kvm2 driver with docker runtime
Times for minikube ingress: 34.3s 35.7s 34.3s 35.8s 35.3s Times for minikube start: 52.3s 48.2s 52.0s 55.2s 55.8s docker driver with docker runtime
Times for minikube start: 22.3s 20.8s 21.6s 21.2s 21.7s Times for minikube ingress: 30.0s 38.0s 36.5s 32.0s 34.5s docker driver with containerd runtime
Times for minikube start: 30.5s 47.6s 43.1s 43.1s 43.0s |
@afbjorklund could this PR legit made minikube start slower ? |
/retest-this-please |
/retest-this-please |
lets pull upstream after this PR is merged #11223 |
@afbjorklund other PR merged. Ready for pulling upstream |
It was silently failing to load from the (wrong) cache directory, causing the image to be download twice from the network instead. Add new function to get the path in the cache directory, so that we don't have to duplicate that both inside and outside module.
@andriyDev
For some reason we do download and load separate for the cache, but not for daemon ? https://github.com/google/go-containerregistry/blob/main/pkg/v1/daemon/write.go#L38 Possibly we should move the remaining function into "download" as well, but name is odd. download.ImagePathInCache Something like: download.ImageFromCache (?) And we still have Docker hardcoded (as Daemon), so there is no support for Podman yet. daemon.Write
|
kvm2 driver with docker runtime
Times for minikube start: 47.5s 45.6s 45.6s 44.9s 50.1s Times for minikube ingress: 43.2s 35.7s 35.2s 34.3s 33.8s docker driver with docker runtime
Times for minikube (PR 11346) ingress: 33.5s 33.0s 35.5s 35.0s 33.5s Times for minikube start: 22.7s 21.7s 22.1s 21.8s 21.8s docker driver with containerd runtime
Times for minikube (PR 11346) start: 41.6s 43.2s 43.2s 47.2s 43.3s |
Now we don't have to expose the local cache directory path, and don't risk mixing the kicbase code with the image code. Duplicate the digest code for now, it should use the Digest implementation Tag() from our patched go-containerregistry.
It allows adding a tag to a Digest, by doing a "docker pull" in the daemon.Write function after doing the "docker load" The digest is not stored in the tarball, so it cannot be loaded from it. The alternative is instead using a Tag.
kvm2 driver with docker runtime
Times for minikube start: 53.0s 52.2s 48.8s 48.1s 54.5s Times for minikube ingress: 34.8s 35.4s 42.7s 34.3s 42.4s docker driver with docker runtime
Times for minikube start: 23.5s 22.1s 22.0s 21.7s 23.3s Times for minikube ingress: 32.5s 32.5s 30.5s 33.0s 31.5s docker driver with containerd runtime
Times for minikube (PR 11346) start: 49.2s 43.3s 47.9s 43.1s 48.0s |
How about instead of making ImageExistsInCache public, we make ImageExistsInDaemon private? Our only use case is in cache.go. We should move that call into download.CacheToDaemon. I am a little concerned however on the semantics of "download.CacheToDaemon" - there's no download involved there, which is a big reason the ImageToCache/Daemon functions were moved from the image package. I wonder if our assumption is wrong. Why do we have ImageToDaemon? Perhaps we should force the only route to be to download to the cache, then load the tarball. Else we may end up having people download images to their docker multiple times through restarts (maybe I'm misunderstanding that though). |
kvm2 driver with docker runtime
Times for minikube (PR 11346) start: 56.1s 52.5s 53.0s 56.3s 51.5s Times for minikube ingress: 37.8s 34.9s 34.8s 36.4s 35.3s docker driver with docker runtime
Times for minikube ingress: 27.5s 33.5s 29.0s 27.5s 33.5s Times for minikube start: 24.9s 21.5s 23.7s 23.4s 23.2s docker driver with containerd runtime
Times for minikube start: 31.2s 44.1s 43.8s 47.5s 48.7s |
Yeah, the name was not great.
I opened a story for it: #11411 Restarting the host docker will not delete the images, though. You would have to use rmi or prune, before they are removed. This can actually be a problem, because currently there are a lot of 1 GB images being added to the code base automatically...
Author: minikube-bot |
I think it currently skips using that function, and instead always tries to load the (possibly non-existent) file and fails silently. download.ImageToCache At some point it should give up on the image and the registry if they fail to download, and move on to the fallback images. It should still work the way it is now, just with some extra logging and some calls that are bound to fail in some places. |
Having "daemon" in the API is not great either, but that was inherited from go-containerregistry However, it is not portable to other engines. It even has a docker client, importing all of that code. github.com/docker/docker/client type imageOpener struct {
ref name.Reference
buffered bool
client Client
} And I guess saving the image to memory or tempfile is going to fail at some point, for any big images. See #8577 (comment) |
} | ||
|
||
// ImageExistsInCache if img exist in local cache directory | ||
func ImageExistsInCache(img string) bool { |
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 dont see this func be used outside download
paockage any reason it is public ?
and also how about we move it to image
package image.ExistsInCache(img)
reads much better than download.ImageExistsInCache
wdyt @afbjorklund
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 would u please (I tried to push to the branch but it didnt let me) |
kvm2 driver with docker runtime
Times for minikube (PR 11346) start: 46.9s 46.3s 47.6s 46.5s 46.0s Times for minikube ingress: 34.2s 35.2s 41.2s 34.2s 33.8s docker driver with docker runtime
Times for minikube start: 22.6s 21.2s 21.8s 22.4s 21.7s Times for minikube (PR 11346) ingress: 32.5s 34.5s 31.5s 29.0s 30.0s docker driver with containerd runtime
Times for minikube start: 30.8s 44.1s 47.0s 42.9s 43.4s |
the containerd test failures seem to be flake |
It was silently failing to load from the (wrong) cache directory,
causing the image to be download twice from the network instead.
Also the name of the function was misleading.
It takes an image, and not actually a filename.
Closes #11321