Odo: weird odo preference file creation behaviour

Created on 22 Jul 2019  Â·  17Comments  Â·  Source: openshift/odo

[kind/bug]

What versions of software are you using?

  • Operating System: Supported
  • Output of odo version: master

How did you run odo exactly?

Step 1:
$ odo project create test
✓ New project created and now using project : test
Amits-MacBook-Pro:odo amit$ odo project create test1 -v4 -w

I0722 13:53:55.215196 2082 preference.go:116] The configFile is /Users/amit/.odo/preference.yaml

I0722 13:53:55.215543 2082 occlient.go:485] Trying to connect to server 192.168.64.2:8443
I0722 13:53:55.216147 2082 occlient.go:492] Server https://192.168.64.2:8443 is up
I0722 13:53:55.234835 2082 occlient.go:415] isLoggedIn err:
output: "developer"
[...]
set: flag accessed but not defined: component
• Waiting for project to come up ...
✓ Waiting for project to come up [322ms]
✓ Project 'test1' is ready for use
✓ New project created and now using project : test1
I0722 13:53:55.569290 2082 odo.go:70] Could not get the latest release information in time. Never mind, exiting gracefully :)

Step 2:
Go to the location of preference file referenced by project create log

Step 3:
Won't find /Users/amit/.odo/preference.yaml path

Actual behavior

No global preference file found

Expected behavior

The preference file should be created. I believe the global preference file should be created under the hood by any odo command except odo version, help.

Any logs, error output, etc?

kinbug point1 prioritLow

All 17 comments

/assign @girishramnani

As of now odo preference set ... only creates the file

@amitkrout according to a past discussion, it was decided that config files should only be created when there is something done with them. until a user doesn't add something to the preferences using odo preference set .. odo consumes all the defaults and hence in my opinion we shouldn't create the file unnecessarily
cc @kadel

we should make the logging message should be made less confusing

@amitkrout according to a past discussion, it was decided that config files should only be created when there is something done with them. until a user doesn't add something to the preferences using odo preference set .. odo consumes all the defaults and hence in my opinion we shouldn't create the file unnecessarily
cc @kadel

agreed, there is no reason to create the file if it will be empty.

@amitkrout

The preference file should be created. I believe the global preference file should be created under the hood by any odo command except odo version, help.

Why do you think that this is needed?

@amitkrout according to a past discussion, it was decided that config files should only be created when there is something done with them. until a user doesn't add something to the preferences using odo preference set .. odo consumes all the defaults and hence in my opinion we shouldn't create the file unnecessarily
cc @kadel

agreed, there is no reason to create the file if it will be empty.

This is not an empty file, its a .yaml file having three keys kind, apiversion and Odosettings. But the values in the dictionary key Odosettings are empty.

Ideally the .yaml file content should look like

kind: Preference
apiversion: odo.openshift.io/v1alpha1
OdoSettings:
  UpdateNotification: true
  NamePrefix:
  Timeout:

@amitkrout

The preference file should be created. I believe the global preference file should be created under the hood by any odo command except odo version, help.

Why do you think that this is needed?

AFAIU this is true that odo consume the default global preference values but what i observe is that values are not reflected in the output. For example UpdateNotification default value is true but it does not reflect in the output.

$ odo preference view
PARAMETER             CURRENT_VALUE
UpdateNotification    
NamePrefix            
Timeout

This should be fixed by making preference file persistent and the default values should be added in the file. Also IMO the command which uses preference as part of their execution should then able to create the preference file if not created or set previously.

AFAIU this is true that odo consume the default global preference values but what i observe is that values are not reflected in the output. For example UpdateNotification default value is true but it does not reflect in the output.

$ odo preference view
PARAMETER             CURRENT_VALUE
UpdateNotification    
NamePrefix            
Timeout

This should be fixed by making preference file persistent and the default values should be added in the file. Also IMO the command which uses preference as part of their execution should then able to create the preference file if not created or set previously.

@amitkrout This was also a conscious decision made with @jorgemoralespou. The reasoning was that the preference view should show transparently whats present in the preference and the cli --help is responsible for showing the defaults.

... the cli --help is responsible for showing the defaults.

Could not get it. What does it mean ?

The reasoning was that the preference view should show transparently whats present in the preference

Does it showing the default values ?
i am expecting atleast something like

$ odo preference view
PARAMETER             CURRENT_VALUE
UpdateNotification   true 
NamePrefix            
Timeout

The reasoning was that the preference view should show transparently whats present in the preference

Does it showing the default values ?
i am expecting atleast something like

$ odo preference view
PARAMETER             CURRENT_VALUE
UpdateNotification   true 
NamePrefix            
Timeout

The argument to not do was as follows - the user could get confused about where the true for UpdateNotification is coming from. Hence a plan to provide the defaults as part of odo config --help was considered.

The reasoning was that the preference view should show transparently whats present in the preference

Does it showing the default values ?
i am expecting atleast something like

$ odo preference view
PARAMETER             CURRENT_VALUE
UpdateNotification   true 
NamePrefix            
Timeout

The argument to not do was as follows - the user could get confused about where the true for UpdateNotification is coming from. Hence a plan to provide the defaults as part of odo config --help was considered.

I don't understand why user will get confuse by seeing the default value true against key UpdateNotification. I feel it will provide more info to the user.

... the cli --help is responsible for showing the defaults.

Could not get it. What does it mean ?

$ odo preference --help
Modifies odo specific configuration settings within the global preference file. 


Available Parameters:
NamePrefix - Default prefix is the current directory name. Use this value to set a default name prefix
Timeout - Timeout (in seconds) for OpenShift server connection check
UpdateNotification - Controls if an update notification is shown or not (true or false)

[...]

From here it is not clear of what happens if i don't set the UpdateNotification

I think what @amitkrout requests can make sense, and it is showing the default value in the preference of it's not explicitly defined. This can be sober by fixing the help message.

sure, then I will fix the help message by showing (Default: x) for each parameter

would that be ok @amitkrout?
cc @kadel

would that be ok @amitkrout?
cc @kadel

Yup, works for me. Then my second concern of command which uses preference as part of their execution should then able to create the preference file will be invalid.

@girishramnani also add a better phrase instead of The configFile is /Users/amit/.odo/preference.yaml for those command uses preference for their reference.

Something like
The preference path reference is [path]/.odo/preference.yaml

I am open to better phrase cc_ @kadel

sure

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jbpratt picture jbpratt  Â·  5Comments

kadel picture kadel  Â·  5Comments

maysunfaisal picture maysunfaisal  Â·  9Comments

surajnarwade picture surajnarwade  Â·  5Comments

kadel picture kadel  Â·  4Comments