priyawadhwa
commented
4 years ago cc @sharifelgamal
Closed matthewmichihara closed 4 years ago
priyawadhwa
commented
4 years ago cc @sharifelgamal
j-windsor
commented
4 years ago If you're looking for another output (looks to be slightly different), I was able repro too.
➜ bin ./minikube start --addons gcp-auth
😄 minikube v1.12.3 on Darwin 10.15.6
✨ Using the docker driver based on existing profile
🎉 minikube 1.13.0 is available! Download it: https://github.com/kubernetes/minikube/releases/tag/v1.13.0
💡 To disable this notice, run: 'minikube config set WantUpdateNotification false'
❗ Requested memory allocation (1990MB) is less than the recommended minimum 2000MB. Kubernetes may crash unexpectedly.
❗ Your system has 16384MB memory but Docker has only 2996MB. For a better performance increase to at least 3GB.
Docker for Desktop > Settings > Resources > Memory
👍 Starting control plane node minikube in cluster minikube
🔄 Restarting existing docker container for "minikube" ...
🐳 Preparing Kubernetes v1.18.3 on Docker 19.03.2 ...
🔎 Verifying Kubernetes components...
🔎 Verifying gcp-auth addon...
📌 Your GCP credentials will now be mounted into every pod created in the minikube cluster.
📌 If you don't want your credentials mounted into a specific pod, add a label with the `gcp-auth-skip-secret` key to your pod configuration.
❗ Enabling 'gcp-auth' returned an error: running callbacks: [verifying gcp-auth addon pods : timed out waiting for the condition: timed out waiting for the condition]
🌟 Enabled addons: default-storageclass, gcp-auth, storage-provisioner
🏄 Done! kubectl is now configured to use "minikube"
❗ /usr/local/bin/kubectl is version 1.16.6-beta.0, which may be incompatible with Kubernetes 1.18.3.
💡 You can also use 'minikube kubectl -- get pods' to invoke a matching version
medyagh
commented
4 years ago I think the problem might be happening because the gcp-auth being enabled before storage-provisioner and the other default addon maybe we should make sure all addons other than the default addons are enabled and started once these two are enabled
matthewmichihara
commented
4 years ago Do you think this is something we can prioritize? The IDEs are looking to leverage this functionality for upcoming features.
tstromberg
commented
4 years ago @medyagh - agreed. This seems to be a short race condition where a webhook is defined, but not yet running. Ideally, we should remove the race condition altogether, but it would be less terrible if we enabled it last or waited for this addon to finish deploying before enabling others.
@matthewmichihara - It's on the list for the next release.
matthewmichihara
commented
4 years ago Thanks for the fix, when should I expect this to show up in gcloud?
Steps to reproduce the issue:
Run
"/Users/michihara/Library/Application Support/google-cloud-tools-java/managed-cloud-sdk/LATEST/google-cloud-sdk/bin/minikube" start --profile cloud-run-dev-internal --keep-context true --wait false --vm-driver docker --interactive false --delete-on-failure --addons gcp-authThis results in a failure. I started seeing this when I added the
--addons gcp-authflag to the command, although when I try to re-run this command without--addons gcp-auth, I still see the same failure.Full output of
minikube startcommand used, if not already included:Optional: Full output of
minikube logscommand: