Closed KarboniteKream closed 1 month ago
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.
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?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Any news? Will the deprecation warning disappear? Or maybe a parameter can be added to the minikube image load
command to permit persistent caching?
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).
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.
Personally I think we should keep both commands, but make the minikube image
ones simpler?
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"
@afbjorklund I agree with you, btw how do you envision to make "image ones simpler" ?
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
When using
minikube cache add
, images are loaded into the active profile and added toconfig.json
. With this entry, the images are loaded into the cluster duringminikube start
.Currently,
minikube cache add
notifies the user that it's going to deprecated and thatminikube image load
should be used instead. However,image load
does not add the entry toconfig.json
, which means that any images loaded with this command would not be restored afterminikube 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 theimage
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