Many local commands block on network.

[warpfork]

The online version check, placed in the default PreRun hooks in the command parser, makes many operations that should be purely local (and consistently fast) into potentially long-blocking calls.

Expected: commands like minikube stop should be able to stop a local VM immediately. It should not depend on whether I'm on flaky cafe wifi ;)

This may accumulate into a significant performance problem if one scripts a series of interactions with minikube -- a half-dozen minikube commands multiplied by a network latency that varies between ~0s and ~15s (my life right now, I know, I know, but it's true) makes what should be a fast and beautiful user story into several minutes of waiting.

Can I disable version checking with a flag or env var of some kind, so my script over $n minikube commands doesn't need to make $n identical network requests?

[warpfork]

Related, previously: #408

[r2d4]

You can add a WantUpdateNotification: false to a ~/.minikube/config/config.yml to disable version checking

[warpfork]

Awesome, that's a solution to my issues. Thanks!

I just checked doing it in both config.yml and config.json and it works in either place.

Is this also settable by flag or env var, if I'm writing a script for other people to use, and don't want to alter their homedir contents?

[r2d4]

Glad that worked for you. As far as the flag/env, its not possible right now but we could consider that for a future release.

I'll let @dlorenc and @aaron-prindle weigh in on that.

[dlorenc]

Yeah it makes sense to me, viper allows binding env vars, right?

On Fri, Aug 12, 2016, 11:55 AM Matt Rickard notifications@github.com
wrote:

Glad that worked for you. As far as the flag/env, its not possible right
now but we could consider that for a future release.

I'll let @dlorenc https://github.com/dlorenc and @aaron-prindle
https://github.com/aaron-prindle weigh in on that.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#479 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABopNu5OcuLOMxKcARM4NKMqhqAkS0nxks5qfMGWgaJpZM4JjQ8P
.

[jimmidyson]

Yep - viper is super flexible & would support automatic binding something like MINIKUBE_WANTUPDATENOTIFICATION. Just a case of enabling it.

[zoidyzoidzoid]

Having it only check occasionally would also be useful, and would make scripts faster the majority of the time too?

Python's pip does a similar thing:

$ cat virtualenv/pip-selfcheck.json                                                                                                                                                                                                             
{"last_check":"2016-08-12T14:56:49Z","pypi_version":"8.1.2"}

[dlorenc]

Yes, we should make the version check asynchronous. The check should only happen once every 24 hours already, but if you run many commands at the same time it's possible they'd all do the check.

[aaron-prindle]

Ref: #671

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close