odo
odo copied to clipboard
odo features reported in a inconsistent way
/kind bug
What versions of software are you using?
Operating System: Win10Pro
Output of odo version:
odo v3.0.0-beta2 (c8e4458f4)
Server: https://api.sandbox-m2.ll9k.p1.openshiftapps.com:6443
Kubernetes: v1.23.5+9ce5071
How did you run odo exactly?
odo list -o json
odo describe component -o json
Actual behavior
odo list -o json reports the features as "runningIn": ["Dev"]
odo describe component -o json reports:
"supportedOdoFeatures": {
"dev": true,
"deploy": false,
"debug": true
}
Expected behavior
Any logs, error output, etc?
they are reporting different things
odo list -o jsonreports the features as"runningIn": ["Dev"]
is the current status. It means that the component is currently running only in "Dev" mode.
odo describe component -o jsonreports:"supportedOdoFeatures": { "dev": true, "deploy": false, "debug": true }
Is reporting what "modes" or features are possible with the given devfile.
This tells you that you can run odo dev and odo dev --debug but the current devfile doesn't support odo deploy that means that it can never be in the "runningIn": ["Deploy"]
You don't get me the issue is Dev vs dev which makes it more difficult to process by integrations
ah, so you mean the inconsistenci in the first letter capitalization?
Yes but also that this information is presented in 2 different forms: an array or a structured object
this information is presented in 2 different forms: an array or a structured object
It is not the same information. For example, once we add support for devfile test commands then supportedOdoFeatures struct will also have test key. but runningIn will never show. test.
supportedOdoFeatures shows what odo commands/features are supported with the current devfile.
runningIn shows in what mode the current devfile is running in
Is the current state problematic?
We could change runningIn into a struct similar to supportedOdoFeatures. The benefit will be that you will see all possible running modes.
The only issue is have is that I need 2 different parsing code for the same information even if one will evolve in the future
The only issue is have is that I need 2 different parsing code for the same information even if one will evolve in the future
That is the thing. They are not the same information.
TBH on my side they are processed quite equally eg menu to stat dev mode is enabled if devfile has dev support and if dev mode is not running for the component.
runningIn: {"dev": true, "deploy": false}
Use lowercase for keys, boolean indicates the mode component is running in.