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

[vrubezhny]

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.

See the details and Steps to Reproduce at: eclipse-che/che#23183

[adietish]

I cannot reproduce this locally. I have the Red Hat Sandbox set as current cluster:

apiVersion: v1
clusters:
- cluster:
    server: https://api.sandbox-XXXXX.openshiftapps.com:6443
  name: api-sandbox-XXXXX-openshiftapps-com:6443
contexts:
- context:
    cluster: api-sandbox-XXXXX-openshiftapps-com:6443
    namespace: adietish-dev
    user: adietish/api-sandbox-XXXXX-openshiftapps-com:6443
  name: adietish-dev/api-sandbox-XXXXX-openshiftapps-com:6443/adietish
current-context: adietish-dev/api-sandbox-XXXXX-openshiftapps-com:6443/adietish
kind: Config
preferences: {}
users:
- name: adietish/api-sandbox-XXXXX-openshiftapps-com:6443
  user:
    token: sha256~XXXXXXXX

When launching the plugin I am logged in, I get the cluster listed.
It's only when my token is outdated that I get the "Login" button instead.

[ibuziuk]

@vrubezhny @adietish is it the same error - https://issues.redhat.com/browse/CRW-7526 ?

[vrubezhny]

@vrubezhny @adietish is it the same error - https://issues.redhat.com/browse/CRW-7526 ?

@ibuziuk There actually could be a few issues:

• The latest versions of GLIBC libs (required by the binaries we use, like oc and odo) aren't available on RHEL8-based workspace image.
• No Kube config file available in user home nor KUBECONFIG env. variable is correctly set (should contain a list of one or more path to Kube config file(-s). This looks more like a workspace configuration issue, not of vscode-openshift-tools extension, but this still results to an activation failures in vscode-openshift-tools (the extension activation failures ate be fixed in 1.18.0, but still the cluster will not be available until Kube config gets available through the USER directory or the paths list in KUBECONFIG env. variable.

There might be some other problems but it's quite difficult to predict any without fixing the CHE-Workspace configuration (RHEL9-based image required + Kube config is to be correctly created and available for the extension) in advance.

When I was testing using the steps to reproduce provided in eclipse-che/che#23183 and UBI9-based Workspace image, the Kube config wasn't available, actually not even HOME env. variable was available, so the extension wasn't able to create an empty Kube config file (which could allow a user to manually connect to some cluster).

So, please, test the extension once again with VSCode Openshift Toolkit v.1.18.0 (released this week) and RHEL8-based CHE-Workspace image becomes finally available.

[vrubezhny]

@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

Closing this issue as resolved. Please feel free to re-open in case of any related issues appear when UBI9 image is used for CHE Workspace.

[adietish]

@vrubezhny: Reopened the issue. There's still a problem with it. See eclipse-che/che#23183 (comment)

[vrubezhny]

@vrubezhny: Reopened the issue. There's still a problem with it. See eclipse-che/che#23183 (comment)

Commented on the mentioned issue: default devfile for sandbox still uses an UBI8 image that has old GLIBC version 2.28, while Openshift CLI requires it to be at least 2.32.
To fix the issue I expect default devfile to be updated to use UBI9, otherwise vscode-openshift-tools isn't functional