odo catalog list services -o json throws error when no services are available

[jeffmaury]

/kind bug

What versions of software are you using?

Operating System:
Win10Pro

Output of odo version:

odo v2.0.0-beta-1 (c19e1f390)       
                                    
Server: https://172.23.121.200:8443 
Kubernetes: v1.11.0+d4cacc0         

How did you run odo exactly?

odo catalog list services -o json

Actual behavior

Exit code is non zero and payload is:

{                                                                                  
        "kind": "Error",                                                           
        "apiVersion": "odo.dev/v1alpha1",                                          
        "metadata": {                                                              
                "creationTimestamp": null                                          
        },                                                                         
        "message": "no deployable services/operators found"                        
}                                                                                  

Expected behavior

Should execute normally and return a payload with an empty list of items

Any logs, error output, etc?

Run against OCP3 (CDK) with only service catalog installed

[dharmit]

The behaviour we're seeing here is observed in more than just one place. For example:

$ odo service list -o json         
{
	"kind": "Error",
	"apiVersion": "odo.dev/v1alpha1",
	"metadata": {
		"creationTimestamp": null
	},
	"message": "Please specify the application name and project name\nOr use the command from inside a directory containing an odo component."
}

$ echo $?
1

The behaviour can be attributed to the use of LogErrorAndExit function which exits with os.Exit(1): https://github.com/openshift/odo/blob/76f306ea5c23c64873828548a3ece33a03174241/pkg/odo/util/cmdutils.go#L56-L57

Changing the behaviour for one command and not for another would be a tough and messy task, I guess. Besides, it would lead to inconsistency and hence bad UX, IMO.

@jeffmaury under what circumstances would you, as a user, prefer exit code be 1 when executing -o json commands?

[jeffmaury]

The rules would be the following:

• if the execution is able to generate the expected JSON output, then exit code should be 0
• otherwise exit code is non zero.

So I'm not complaining about the exit code but rather against the generated JSON output that should be one expected with an empty list

[girishramnani]

The behaviour we're seeing here is observed in more than just one place. For example:

$ odo service list -o json         
{
	"kind": "Error",
	"apiVersion": "odo.dev/v1alpha1",
	"metadata": {
		"creationTimestamp": null
	},
	"message": "Please specify the application name and project name\nOr use the command from inside a directory containing an odo component."
}

$ echo $?
1

The behaviour can be attributed to the use of LogErrorAndExit function which exits with os.Exit(1):

https://github.com/openshift/odo/blob/76f306ea5c23c64873828548a3ece33a03174241/pkg/odo/util/cmdutils.go#L56-L57

Changing the behaviour for one command and not for another would be a tough and messy task, I guess. Besides, it would lead to inconsistency and hence bad UX, IMO.

@jeffmaury under what circumstances would you, as a user, prefer exit code be 1 when executing -o json commands?

this is expected because there is an error in the way the command was used @dharmit .

but what @jeffmaury is mentioning is a valid bug. The idea with listing any resource is that it shouldn't error out when there are no services because that is not an error. It is an expected state when the user is starting their cluster.

[girishramnani]

Now if the service catalog or operator hub is not enabled for the user then that should be an error because its something that we want the user to rectify.

[jeffmaury]

Yes but from a tooling experience, this error should not be returned as a process exit code as the tooling will have no way to interpret it unless the error code are property documented so it should returned as a documented JSON output