eclipse-che
VS Code OpenShift Toolkit extension does not detect connection on the cluster it is deployed on
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
- open workspace with VS Code OpenShift tolkit extension, for instance https://github.com/apupier/reproducer-che-vscode-openshift
- Trust authors
- Wait for the install of the extensions
- Open the Kuebrnetes perspective and notice the connection available to the local OpenShift cluster:
- 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
@vrubezhny is looking at it in https://github.com/redhat-developer/vscode-openshift-tools/issues/4535.
@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?
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.
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:
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
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
@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).
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).
Depends on the https://github.com/eclipse-che/che/issues/23034 to be solved.
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)
@apupier Do you have ~/.kube/config existing? Could you check this, please?
@apupier Do you have
~/.kube/configexisting? 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
OK, then it looks like https://github.com/redhat-developer/vscode-openshift-tools/issues/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.
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: https://github.com/redhat-developer/vscode-openshift-tools/pull/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.
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
The VSCode Openshift Toolkit activation doesn't fail anymore when using the v.1.18.0...
... but still, when trying to open CHE workspace, I have $HOME = / and no Kube config created, so Openshift Toolkit can't show any information on the cluster it's connected to nor watch for the Kube config changes. The same goes to the Kubernetes extension as well.
@ibuziuk Problem is that starting the CHE workspace using the @apupier's example (a bit modified) I don't get $HOME variable set properly (it suddenly resolves to /) and I don't have any /home/user/.kube folder created:
So, for my example the Kube config doesn't get injected... Even $HOME var. isn't set properly... That's why I told that probably I'm using a wrong way/configuration to start CHE Workspace.
@vrubezhny well, in your sample the image does not have oc available e.g. https://github.com/che-incubator/quarkus-api-example/pull/54 seems to work fine
@apupier could you please review and let us know if the issue can be resolved?
@adietish @ibuziuk @apupier Thanks!
VSCode Openshift Tools works as expected after I modified @apupier's reproducer example with the the image and some other container properties from quarkus-api-example suggested by @ibuziuk.
The resulting reproducer example is used to start the ^^^ workspace: https://github.com/vrubezhny/reproducer-che-vscode-openshift/blob/master/readme.md
So, I believe, this issue can be closed as resolved now.
If I understand well, the image provided by default on the Red Hat developer sandbox is not configured to have the connection automatically created?
When using https://github.com/apupier/reproducer-che-vscode-openshift , which is using the default devfile, the connection is not available. When using https://github.com/vrubezhny/reproducer-che-vscode-openshift/blob/master/readme.md , which is using a custom devfile, the connection is available.
What is the reason to prevent it working out of the box?
@vrubezhny indeed, it does not seem to work with http://workspaces.openshift.com/#https://github.com/apupier/reproducer-che-vscode-openshift
@adietish there is still a problem on the extension end I believe
@ibuziuk looks like it 😢 . Will point @vrubezhny to it when he gets back next week. Reopened https://github.com/redhat-developer/vscode-openshift-tools/issues/4535 and added it to the current sprint.
@apupier @adietish @ibuziuk IMHO, That's not a RHEL9-based image Workspace. At least it still has GLIBC v.2.28...
... while the OpenShift Client binary requires it to be at least of version 2.32:
@apupier @adietish @ibuziuk When quay.io/devfile/universal-developer-image:ubi9-latest image is used - everything works well (see the test example here)
If I understand well, the image provided by default on the Red Hat developer sandbox is not configured to have the connection automatically created?
That's not only about the connection. vscode-openshift-tools needs GLIBC >= v.2.32 for Openshift CLI (oc) to make it possible to be executed. It won't work with UBI8 (RHEL8-based) images
So, I expect the default devfile to be changed to use an UBI9 image
So, I expect the default devfile to be changed to use an UBI9 image
based on https://github.com/redhat-developer/devspaces-images/commit/1da57d328b07662e19ddc50168c5a0d55830fdd6 i would expect to have UBI9 already. Wondering why the UBI 9 is not already the default one
UBI 9 is going to be the default as part of the https://github.com/eclipse-che/che/issues/23321 cc @martinszuc @vrubezhny however, I do not quite grok why it does not work with UBI 8 - https://github.com/eclipse-che/che/issues/23183#issuecomment-2755153665
On the screenshot, you can see that HOME, kubeconfig, etc, are all set. Why the extension can not process it correctly?
@vrubezhny however, I do not quite grok why it does not work with UBI 8 - #23183 (comment)
On the screenshot, you can see that HOME, kubeconfig, etc, are all set. Why the extension can not process it correctly?
it is because the oc binary embedded requires a newer version of glibc than what is available in RHEL 8