VS Code OpenShift Toolkit extension does not detect connection on the cluster it is deployed on

[apupier]

Describe the bug

VS Code OpenShift Toolkit extension does not detect connection on the cluster it is deployed on even if VS Code Kubernetes is able to detect it

Che version

7.92@latest

Steps to reproduce

1. open workspace with VS Code OpenShift tolkit extension, for instance https://github.com/apupier/reproducer-che-vscode-openshift
2. Trust authors
3. Wait for the install of the extensions
4. Open the Kuebrnetes perspective and notice the connection available to the local OpenShift cluster:
   
5. Open the OpenShift perspective and notice that no connection is available:
   

Expected behavior

to have connection visible in VS Code OpenShift perspective

Runtime

OpenShift

Screenshots

No response

Installation method

other (please specify in additional context)

Environment

Dev Sandbox (workspaces.openshift.com)

Eclipse Che Logs

No response

Additional context

No response

[ibuziuk]

@adietish could you please take a look ?

[adietish]

@vrubezhny is looking at it in redhat-developer/vscode-openshift-tools#4535.

[vrubezhny]

@apupier Could you , please, tell if this issue is a regression?
I mean, did it work as expected until vscode-openshift-tools v.1.14.0 was released or did it never detect the connection in the cluster it runs on?

[apupier]

I'm not sure.
I remember it was connecting automatically several months (years?) ago but given that it was long time ago I'm not sure if I was using VS code Kubernetes only or if I was using VS Code OpenShift Toolkit.

[vrubezhny]

The screenshots you posted show different extensions - the first one (logged in) is from Kubernates extension, while the second one (not logged in) is from Openshift Tools extension. I haven't seen how Openshift Tools extension was behaving when running on the cluster (whether it was logged in the same way as K8s extension or not), but if K8s extension was configuring somehow the "current" cluster we're running on into the "current-context" property in Kube config then Openshift extension could pick that new context after it was created.
Starting from v.1.14.0 Openshift extension doesn't depend on/required K8s extension to be installed - so on the first run (using your reproducer example) I see "...configuration cannot be loaded..." error instead of being logged in:

[apupier]

I reproduce the new issue with Kubernetes extension, so means we have another different regression with VS Code Kubernetes.

By looking to Output ->OpenShift, I found this kind of error:

/checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/odo-linux-amd64-b4853e1fa: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/odo-linux-amd64-b4853e1fa)
/checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/odo-linux-amd64-b4853e1fa: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/odo-linux-amd64-b4853e1fa)
"/checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/odo-linux-amd64-b4853e1fa" version --client

/checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/oc: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/oc)
/checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/oc: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/oc)
/checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/oc: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/tools/linux/oc)
oc projects -q
openshift-virtualization-os-images

In Output ->Extension host (remote):

2024-11-25 13:18:29.487 [error] Error: Failure to get workspace pod. ENOENT: no such file or directory, open '/home/user/.kube/config'
	at p.updateContainers (/checode/checode-linux-libc/ubi8/extensions/che-resource-monitor/dist/extension.js:2:2305424)
	at p.show (/checode/checode-linux-libc/ubi8/extensions/che-resource-monitor/dist/extension.js:2:2304424)
	at p.start (/checode/checode-linux-libc/ubi8/extensions/che-resource-monitor/dist/extension.js:2:2304318)
	at e.activate (/checode/checode-linux-libc/ubi8/extensions/che-resource-monitor/dist/extension.js:2:2729237)
	at async m.n (/checode/checode-linux-libc/ubi8/out/vs/workbench/api/node/extensionHostProcess.js:144:6409)
	at async m (/checode/checode-linux-libc/ubi8/out/vs/workbench/api/node/extensionHostProcess.js:144:6372)
	at async m.l (/checode/checode-linux-libc/ubi8/out/vs/workbench/api/node/extensionHostProcess.js:144:5829)

and

2024-11-25 13:18:30.140 [error] Error: Kubernetes configuration cannot be loaded. Please check configuration files for errors and fix them to continue.
	at new KubeConfigUtils (/checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/src/util/kubeUtils.js:44:19)
	at Oc.fixActiveProject (/checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/src/oc/ocWrapper.js:553:21)
	at /checode/remote/extensions/redhat.vscode-openshift-connector-1.16.0-linux-x64/out/src/oc/ocWrapper.js:532:44

the Kubernetes ouput is strangely completely empty

[apupier]

based on this command in the terminal:

reproducer-che-vscode-openshift (master) $ ldd --version
ldd (GNU libc) 2.28
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

it seems that the base image is containg a too old version glibc compared to what the oc and odo binaries used by the extension are supporting

[vrubezhny]

@apupier Do we have any idea on how we can change/update the base image so it has the required version of GLIBC?

oc/odo are the binaries we embed and use as is and we need these binaries to be fully functional. And this problem could be the one of the reason we cannot login to the cluster we're running on (actually to any cluster).

[vrubezhny]

Yes, I've checked - alizer, oc, odo CLI binaries we use require GLIBC 2.32+/2.34+ while func and helm CLI binaries work don't (or work well with the provided lib version) - the binaries of the latest versions are bundled together with the OSTools extension, so the extension fails to work as expected.
Kubernetes extension looks like is using the oc CLI binary found in user's PATH (which is compatible) - so it works well (at least it shows what cluster it is logged in to).

[vrubezhny]

Depends on the #23034 to be solved.

[apupier]

finally manged to start with a udi9 image

https://github.com/apupier/reproducer-che-vscode-openshift-udi9

schemaVersion: 2.1.0
metadata:
   name: helloworld-example
components:
  - name: dev-tooling
    container:
      image: registry.access.redhat.com/ubi9/ubi:9.5
      args: ['tail', '-f', '/dev/null']

but the VS COde extension Toolkit extension is not able to activate:

2024-11-29 15:13:43.242 [error] Activating extension redhat.vscode-openshift-connector failed due to an error:
2024-11-29 15:13:43.242 [error] TypeError: this.kubeConfigWatchers is not iterable
   at new lo (/checode/remote/extensions/redhat.vscode-openshift-connector-1.17.0-linux-x64/out/src/extension.js:298:7754)
   at lo.getInstance (/checode/remote/extensions/redhat.vscode-openshift-connector-1.17.0-linux-x64/out/src/extension.js:298:8286)
   at Y8i (/checode/remote/extensions/redhat.vscode-openshift-connector-1.17.0-linux-x64/out/src/extension.js:341:7810)
   at W.kb (/checode/checode-linux-libc/ubi9/out/vs/workbench/api/node/extensionHostProcess.js:167:13836)
   at W.jb (/checode/checode-linux-libc/ubi9/out/vs/workbench/api/node/extensionHostProcess.js:167:13508)
   at /checode/checode-linux-libc/ubi9/out/vs/workbench/api/node/extensionHostProcess.js:167:11493
   at async m.n (/checode/checode-linux-libc/ubi9/out/vs/workbench/api/node/extensionHostProcess.js:151:6409)
   at async m (/checode/checode-linux-libc/ubi9/out/vs/workbench/api/node/extensionHostProcess.js:151:6372)
   at async m.l (/checode/checode-linux-libc/ubi9/out/vs/workbench/api/node/extensionHostProcess.js:151:5829)

[vrubezhny]

@apupier Do you have ~/.kube/config existing? Could you check this, please?

[apupier]

@apupier Do you have ~/.kube/config existing? Could you check this, please?

It seems I have no ~/.kube/config available. The VS Code Kubernetes extension is not finding the connection neither this time

[vrubezhny]

OK, then it looks like redhat-developer/vscode-openshift-tools#3872 is still reproducible.

PS: VS Openshift Toolkit doesn't depend on VS Kubernetes extension, so you don't need to add the last one to your extension.json. But you may still need to have it to check how do the extensions work in regard of logging in and/or other functions.

[vrubezhny]

But, all I can do here is to create a ~/.kube/config with a minimalistic contents (or report an error if it cannot be created), so the extension can be successfully activated.
See: redhat-developer/vscode-openshift-tools#4676

However I wouldn't (even if I can) define any clusters/users/contexts properties (especially pointing to a cluster and user currently logged in - this preferably is to be done during the workspace configuration and before the extension starts.

[vrubezhny]

For the UDI 9 image, it looks like the system environment variables aren't set properly... At least $HOME:

And this is also, probably, why the ~/.kube/config wasn't properly created