minikube cache does not work as expected

[BartJansseune]

What Happened?

Context:
containerd runtime
hyperv driver

When you perform a minikube cache reload, images are always reloaded into minikube because the hash that minikube derives from the tar file does not correspond with the hash that is reported by containerd (ctr).

Here's an extract from the log:
Line 6: I1116 15:59:26.521389 32088 ssh_runner.go:195] Run: /bin/bash -c "sudo ctr -n=k8s.io images check | grep redis"
Line 29: I1116 15:59:28.089851 32088 ssh_runner.go:235] Completed: /bin/bash -c "sudo ctr -n=k8s.io images check | grep redis": (1.5679596s)
Line 33: I1116 15:59:28.090359 32088 cache_images.go:116] "redis" needs transfer: "redis" does not exist at hash "e10bd12f0b2d6a1ff41c9555ebb2c65056ae612bc074f5f46ebf36e5445346cd" in container runtime
Line 38: I1116 15:59:28.091406 32088 localpath.go:146] windows sanitize: C:\ProgramData\Minikube.minikube\cache\images\amd64\redis -> C:\ProgramData\Minikube.minikube\cache\images\amd64\redis
Line 39: I1116 15:59:28.092953 32088 cri.go:216] Removing image: redis
Line 65: I1116 15:59:30.473989 32088 ssh_runner.go:195] Run: sudo /usr/bin/crictl rmi redis
Line 68: I1116 15:59:30.651216 32088 cache_images.go:286] Loading image from: C:\ProgramData\Minikube.minikube\cache\images\amd64\redis
Line 69: I1116 15:59:30.657076 32088 ssh_runner.go:195] Run: stat -c "%s %y" /var/lib/minikube/images/redis
Line 73: I1116 15:59:31.592669 32088 ssh_runner.go:356] copy: skipping /var/lib/minikube/images/redis (exists)
Line 81: I1116 15:59:33.566320 32088 containerd.go:269] Loading image: /var/lib/minikube/images/redis
Line 82: I1116 15:59:33.572283 32088 ssh_runner.go:195] Run: sudo ctr -n=k8s.io images import /var/lib/minikube/images/redis
Line 83: I1116 15:59:35.325326 32088 ssh_runner.go:235] Completed: sudo ctr -n=k8s.io images import /var/lib/minikube/images/redis: (1.7530428s)
Line 84: I1116 15:59:35.325326 32088 cache_images.go:315] Transferred and loaded C:\ProgramData\Minikube.minikube\cache\images\amd64\redis from cache

When you have a lot of cached images, this extends the startup time significantly

Attach the log file

log.txt

Operating System

Windows

Driver

Hyper-V

[afbjorklund]

It is supposed to use the same hash as reported by crictl (similar to what kind is using)

• cache reload does not appear to be working properly #10060

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[BartJansseune]

Issue can be closed, Solved in v1.32.1

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.