kubernetes / minikube

Run Kubernetes locally
https://minikube.sigs.k8s.io/
Apache License 2.0
29.53k stars 4.89k forks source link

Persisting images across cluster resets with `minikube image load` #17985

Closed KarboniteKream closed 1 month ago

KarboniteKream commented 10 months ago

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 commented 10 months 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.

afbjorklund commented 10 months ago

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 commented 7 months ago

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

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

You can:

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

/lifecycle stale

k8s-triage-robot commented 6 months ago

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:

You can:

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

/lifecycle rotten

k8s-triage-robot commented 5 months ago

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:

You can:

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

/close not-planned

k8s-ci-robot commented 5 months ago

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

In response to [this](https://github.com/kubernetes/minikube/issues/17985#issuecomment-2181219818): >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][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
ImAARIX commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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?

medyagh commented 2 months ago

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 commented 2 months ago

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

k8s-triage-robot commented 1 month ago

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:

You can:

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

/close not-planned

k8s-ci-robot commented 1 month ago

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

In response to [this](https://github.com/kubernetes/minikube/issues/17985#issuecomment-2423086920): >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][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.