-
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
Changing MINIKUBE_HOME after VM creation does not work without cluster recreation #14466
Comments
Hi @pre, thanks for reporting your suggestion to minikube. Offhand I'm not sure the amount of work this would require, but I agree this would be an ideal use case and would support any PR that implements this. |
Hi @spowelljr, I dig a little bit into this issue and the problem is caused that in Potentially we could fix this in minikube/pkg/minikube/machine/fix.go Line 53 in 96c16fe
AuthOptions but for Driver it's a little bit tricky cause api.Load minikube/pkg/minikube/machine/fix.go Line 60 in 96c16fe
*host.Host and Driver is a interface without possibility to modify StorePath field.
In other approach we could directly modify json file but I don't think that this is the good idea. What do you think about this? |
I thought of a few possible solutions: Solution 1: Instead of storing the whole path for everything we could store the non-dynamic values and then just append it to For example Problem 1: This would break configs from previously generated configs (ie. ones that have the full path) Solution 2: Could add a config update command, it will go though the config and update paths to the new path. Example: Copy I'm open to other ideas as well |
/assign |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
What Happened?
Due to "enterprise reasons" we had to move
~/.minikube
to~/something_else/.minikube
.An ideal migration without cluster recreation would be:
mv ~/.minikube ~/something_else/.minikube
export MINIKUBE_HOME="${HOME}/something_else/.minikube"
But what happens is changing
MINIKUBE_HOME="${HOME}/something_else/.minikube"
has no effect when cluster vm has already been created (log below).This can be temporarily fixed with symlink
ln -s ~/something_else/.minikube ~/.minikube
.The catch is that we a have an extensive locally scripted setup shared between dozen of developers. "It would be nice" if MINIKUBE_HOME was not set in stone in such a way that the cluster would not have to be recreated if MINIKUBE_HOME was changed and the files were moved externally from Minikube.
This would minimize the pain of "how to migrate to a newer local setup" in such a scenario where a locally scripted minikube setup is essential to a group of people.
Attach the log file
Operating System
macOS (Default)
Driver
Docker
The text was updated successfully, but these errors were encountered: