odo describe component does not work when logged out of cluster

[dgolovin]

/kind bug

What versions of software are you using?

Operating System: linux

Output of odo version

~/p/vscode-openshift-tools/out/tools/linux/odo version
odo v3.3.0 (1d315866b)

Server: https://api.sandbox-m2.ll9k.p1.openshiftapps.com:6443
Kubernetes: v1.24.6+5157800

How did you run odo exactly?

 ~/p/vscode-openshift-tools/out/tools/linux/oc whoami
Error from server (Forbidden): users.user.openshift.io "~" is forbidden: User "system:anonymous" cannot get resource "users" in API group "user.openshift.io" at the cluster scope

odo describe component

Actual behavior

 ~/p/vscode-openshift-tools/out/tools/linux/odo describe component
 ✗  failed to get ingresses/routes: ingresses.networking.k8s.io is forbidden: User "system:anonymous" cannot list resource "ingresses" in API group "networking.k8s.io" in the namespace "nivologd-dev"

Expected behavior

odo prints out human readable output

Any logs, error output, etc?

See actual behavior section.

[sbouchet]

@dgolovin :
cannot reproduce on RHEL.

sbouchet@sbouchet:Empty$ /home/sbouchet/.odo/cache/3.3.0/odo version
odo v3.3.0 (1d315866b)
sbouchet@sbouchet:Empty$ /home/sbouchet/.odo/cache/3.3.0/odo describe component
 ⚠  No connection to cluster defined
Name: node
Display Name: Node.js Runtime
Project Type: Node.js
Language: JavaScript
Version: 2.1.1
Description: Stack with Node.js 16
Tags: Node.js, Express, ubi8

Running in: None

Supported odo features:
 •  Dev: true
 •  Deploy: false
 •  Debug: true

Container components:
 •  runtime

The output of odo version still shows you're connected to a cluster.

[dgolovin]

@sbouchet Thank you for verifying that. Do you actually have current-context set in ~/.kube/config? I have the same issue on MacOS. If I have current-context pointed to crc instance that is not running at the moment, I have the same issue.

In my case that cleans Components View, because every 'odo describe component' command fails and extension cannot detect components inside workspace.

We can - of course - workaround this and just look for devfile.yaml/.devfile.yaml to detect odo components in workspace.

[sbouchet]

@sbouchet Thank you for verifying that. Do you actually have current-context set in ~/.kube/config? I have the same issue on MacOS. If I have current-context pointed to crc instance that is not running at the moment, I have the same issue.

No, I d'ont have any context set:

sbouchet@sbouchet:Empty$ kubectl config current-context
error: current-context is not set

So this error raises because the current context stills points to a non existing reachable cluster. I'll try to change context to reproduce.

In my case that cleans Components View, because every 'odo describe component' command fails and extension cannot detect components inside workspace.

We can - of course - workaround this and just look for devfile.yaml/.devfile.yaml to detect odo components in workspace.

[feloy]

For the moment, we are handling correctly only the case when a kubeconfig file is not present, and so odo cannot build a config to access the cluster. This is the easiest case because configuration is built at startup time. In this case, we are not trying to do any operation on the cluster.

Other real-time cases (cluster endpoint not accessible, timeout, logged out, etc) are not detected at initialization time. We need to work on these scenarios to make these errors non blocking for the other (local) operations, and just displaying some warning to the user.

One question is how would you like to have the information in JSON output that connection to cluster failed, and so some fields are just unknown? In human readable form, we can display some warning, but not in JSON output. We could discuss this point next tuesday

[dgolovin]

@feloy Please preserve behavior between releases, it has changed (again), because v3.0.0 was working fine without active connection to the cluster, and we used 'odo describe component' to detect odo component in folders added to vscode workspace. Now that is not working without active connection.

Adding new info into 'odo describe component' is not a problem. You can always add new info into json output, but in a way that does not affect access to info that was in previous release. What it means, if you have a json output structured as

{
a: value-for-a, 
b: value-for-b
}

you can release new version that has

{
a: value-for-a, 
aa: value-for-aa, 
b: value-for-b,
bb: value-for-bb
}

but not

{
 improved-sturcture-prop:
      {
      a: value-for-a, 
      b: value-for-b
      }
}

or

{
better-name-for-a: value-for-a, 
b: value-for-b
}

We can always find workaround for that, like if odo describe component does not work for us, we can update our detection process to just looking for devfile.yaml. That, though, undermines the whole idea of using odo, because if we can detect component w/o odo eventually we can start deploying it without odo :)

[dgolovin]

TLDR: We do not need any info about cluster accessibility in json, just get the same behavior back would be the best fix.

[valaparthvi]

Marking this as critical-urgent because it a release blocker for the Adapters's team. We'd like to get this in the upcoming release.

[kadel]

TLDR: We do not need any info about cluster accessibility in json, just get the same behavior back would be the best fix.

This regression was accidentally introduced when we added a listing of Ingress and Route URLs (#6244). This behavior was not intentional.