Improve update checker

[kadel]

Current implementation noticeably slows ocdev execution even on a really fast internet connection.

We definitely should have an option to disable this check permanently. We could have something like ocdev config set checkForUpdates false and use config file to persist configuration.

We could also perform check only once a day (use config file to persist when check occurred last time)
we can do those in separate PR, but think that we definitely have to add a way to disable it.

Another option could be to perform check as async operation.

---

Update: 2018-07-12

Summary:

There are two things that are needed.

First

We need a configuration uption that will disable update checker.

There should be new commadn odo config

# disable update notification
odo config set UpdateNotification false

# view current value
odo config get UpdateNotification

UpdateNotification = false

Value of UpdateNotification is saved in config file.
There is Config struct in config.go that represent ODO config file structure. (

odo/pkg/config/config.go

Line 31 in 4567402

type Config struct {

)
There should be a new field called UpdateNotification.
odo config set UpdateNotification false sets value of this field to false, (or true if odo config set UpdateNotification true is called)

Update checker should be started only when this configuration field is set to true.
Default value if the configuration is not specified is true

Second

We need a better way to check for updates that don't require calling GitHub API.

TBD

[concaf]

Update: @baijum gave some nice pointers on how to solve this in https://gist.github.com/baijum/036a79ec2e85279af596d0a2a3e0e13e, continuing work.

[kadel]

reopening

Let's close this after we implement option to completely disable checking for updates

[kadel]

we could implement configuration subcommand similar to minikube:

# disable update notification
ocdev config set UpdateNotification false


# view current value
ocdev config get UpdateNotification
UpdateNotification = false

[kadel]

Also, we are fetching latest information from GitHub API. Problem is that this will hit Github API rate limiting after a few odo runs. We should check for latest release number in some other way.

[surajnarwade]

@kadel instead of hitting github API, can we have file like this, https://github.com/openshift/origin/blob/master/.release which we will update at every release ?

[kadel]

We already have a version number in https://github.com/redhat-developer/odo/blob/master/cmd/version.go could we used that?
Or modify version.go to read .release?

[kadel]

@syamgk what is the status of this?

[syamgk]

working will push the initial commit today

[syamgk]

WIP PR can be found here #589

[syamgk]

also #593 for eliminate calling GitHub API for version fetching

[jorgemoralespou]

Please, @kadel and all, don't use this signature for configuration of the CLI itself. This signature should be used for configuration of a component, meaning adding configuration to it in the form of an environment variable or a file, whether internally as a secret or configmap or value directly on the deployment.

For CLI configuration I would propose one of the following alternatives:

• $ odo option set timeout 2
• $ odo adm option set timeout 2
• $ odo adm config set timeout 2

And use set/unset/clear as verbs, instead of "create,update,delete"

[kadel]

@jorgemoralespou You are right, it makes much more sense to reserve odo config for component configuration.

I don't like odo adm to be honest. It just looks a bit weird to me.

We have odo utils command. (odo utils completion and odo utils terminal).
Would it make sense to have odo utils option?
Or we could rename utils to something better more suitable. It would be nice to have one common root command under which we can put all non component/application related stuff.

[jorgemoralespou]

I never liked utilsmyself :-D but yes, should probably belong in the same "option namespace" so whatever we decide as naming for this, should potentially all go there.

@gshipley @marekjelen any idea on how to name this?

[marekjelen]

I am pretty much OK with the utils, as the name imho represents what’s in the namespace.

For the tool config option seems like a good candidate. setup might work, but it may not be as intuitive.

[syamgk]

so renaming it from config and configuration to utils and utility on my PR

[kadel]

so renaming it from config and configuration to utils and utility on my PR

we can leave it as utils, utility is just more letters to type :-)

commands should be odo utils option set/odo utils option get or odo utils config set/odo utils config get

[Jessica6552]

Humm

[syamgk]

closing this issue since these three pr's got merged
#613
#593
#589