Persisting images across cluster resets with minikube image load

[KarboniteKream]

When using minikube cache add, images are loaded into the active profile and added to config.json. With this entry, the images are loaded into the cluster during minikube start.

Currently, minikube cache add notifies the user that it's going to deprecated and that minikube image load should be used instead. However, image load does not add the entry to config.json, which means that any images loaded with this command would not be restored after minikube delete && minikube start.

Are there any plans or desire to introduce image persistence across cluster resets to image load command?

I started working on adding support for updating config.json, but I realized this approach might not be what you want for the image command, so I wanted to discuss it with you in this issue first. For example, we probably want to have separate cache for each profile.

Quick implementation to replicate cache add: https://github.com/KarboniteKream/minikube/tree/feat/image-load-persist

[spowelljr]

That deprecation warning was added two years ago by someone who no longer works on the project when they added the image load command. I'm not aware of any plans for any actual deprecation, so maybe we can remove the warning? I don't know if @afbjorklund has any info on this.

[afbjorklund]

I think the deprecation warning is obsolete/misleading, and that the "minikube cache" and "minikube image" are using the same caching code - the main difference is if they "remember" the images for next time.

Separating the list of images per profile sounds like an interesting idea, as long as they still share the same image cache. But the list itself could be split into a global list, and a list that is kept for each profile/cluster?

[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

[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-sigs/prow repository.

[ImAARIX]

Any news? Will the deprecation warning disappear? Or maybe a parameter can be added to the minikube image load command to permit persistent caching?

[ImAARIX]

Hi @afbjorklund @spowelljr (and maybe @medyagh).
It appears that this issue was automatically closed due to inactivity, which I believe is a mistake.
The deprecation message is still there on v1.33.1, but there's no other deprecation notice or GitHub issue talking about that.

It's an important functionnality of Minikube, that offer the ability to keep images in cache after doing a minikube delete, that have no real alternatives (beside adding images tags to the $MINIKUBE_HOME/config/config.json in "cache" attribute by hand or by using minikube config set cache command, but the second one is more difficult to use).

[afbjorklund]

It appears that this issue was automatically closed due to inactivity, which I believe is a mistake.

The bot does that automatically, and it does not necessarily represent a decision or project direction.

---

I think we need some clarification on each command, and then some refactoring and clean up.

• Document minikube image semantics about locations #12270

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

Personally I think we should keep both commands, but make the minikube image ones simpler?

[medyagh]

we dont have a plan to actually stop allowing using the "cache add" however for most users I would recommend them use "image load" for local develpoment instead of cache add, cache add is meant to be across all clusters,

what we could do is change the wording of deprication to "suggested use image load for develoeprs"

[medyagh]

@afbjorklund I agree with you, btw how do you envision to make "image ones simpler" ?

[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-sigs/prow repository.