Proof of concept working in Eclipse Che with Code Server

[apupier]

It would be nice to have the extension working in Eclipse Che with Code server

[apupier]

currently not working by default because native Kaoto backend requires RHEL 9 and rhel 8 is used by Dev Spaces.

Asked on internal Eclipse Che Red Hat chat to use rhel 9 https://chat.google.com/room/AAAAm3qdpQU/5g-BUCTta-0

[lhein]

was there a specific reason why we require RHEL 9 on backend side, @Delawen ?

[apupier]

for reference, there is this kind of error:

Error: /jenkins/workspace/Fuse/VSCode/vscode-kaoto-release/test-resources/redhat.vscode-kaoto-0.3.0/binaries/kaoto-linux-amd64: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /jenkins/workspace/Fuse/VSCode/vscode-kaoto-release/test-resources/redhat.vscode-kaoto-0.3.0/binaries/kaoto-linux-amd64)
/jenkins/workspace/Fuse/VSCode/vscode-kaoto-release/test-resources/redhat.vscode-kaoto-0.3.0/binaries/kaoto-linux-amd64: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /jenkins/workspace/Fuse/VSCode/vscode-kaoto-release/test-resources/redhat.vscode-kaoto-0.3.0/binaries/kaoto-linux-amd64)

I think that it comes from GraalVM/Mandrel/Quarkus version which is creating the native build with a more recent version required of glibc (the one in rhel 8 is quite old, it has only security updates for several years now). or the glibc version used at the time of building the native image.

[apupier]

To have it working by default in Dev Sandbox, see https://issues.redhat.com/browse/CRW-3185

It should be possible to have it working in dev sandbox or other Eclipse Che based on:

• https://issues.redhat.com/browse/CRW-3261d
• VS Code for Eclipse Che works with both UBI 8 and 9 eclipse-che/che#21629
• https://github.com/che-incubator/che-code/tree/main/build/dockerfiles#running-visual-studio-code---open-source-code---oss-in-a-ubi9-based-container

[tplevko]

Just adding my findings - Tried it today with the latest eclipse che - seems like the plugin is working with the latest che operator version.
I was also able to get it running with the code server, specifically this flavour of code server - https://hub.docker.com/r/linuxserver/code-server

I was only able to run the current released version working. It would be good to explore possibilities of running the dev version.

[apupier]

the base image seems to be a recent Ubuntu https://github.com/linuxserver/docker-code-server/blob/master/Dockerfile#L1 which is providing a recent enough version of glibc.
I guess you modified the image to use for the IDE part, right? Can you share the devfile config then?

I was only able to run the current released version working. It would be good to explore possibilities of running the dev version.

What is the problem with the snapshot version?

[tplevko]

There wasn't any modification necessary. The extension actually worked OOTB with the image provided.

And related to the snapshot version, I didn't mean there was a problem, just that I didn't yet figure out, how to get the current dev version running in the code server image, or with eclipse che and it would be worth investigating.

[lordrip]

Still not working in Red Hat developer sandbox 😞

[lordrip]

Currently, we're downloading the three builds of Kaoto backend, could we only download the required one for the current platform?

If we could do this, could we add another build of Kaoto backend using the old library? this way we could check which version of GCLib we have and then download the correct version.

[apupier]

Currently, we're downloading the three builds of Kaoto backend, could we only download the required one for the current platform?

it is possible: #89

If we could do this, could we add another build of Kaoto backend using the old library? this way we could check which version of GCLib we have and then download the correct version.

Unfortunately it won't be enough with built-in functionalities of VS Code. VS code is providing a mechanism only based on system architecture. The problem here is not about different architecture but about different version of GLIB_C.

it implies 2 things:

• implement our own mechanism to select/download the native binary
• be able to produce a binary compatible with older version of GLIB_C

I think better paths to support Kaoto in Red Hat Developer sandbox are either:

• use a Java all-in-one artifact for the server
• push for Eclipse Che to be based on more recent images by default (i.e. RHEL 9 instead of RHEL 8) see https://issues.redhat.com/browse/CRW-3185
• provide examples using a RHEL 9 image (which is supposed to be possible, see Proof of concept working in Eclipse Che with Code Server #102 (comment) )

[lordrip]

Even if the Red Hat Developer sandbox gets updated to RHEL 9.0, wouldn't we be leaving users behind? maybe users that haven't got the latest RHEL or Fedora yet?

[apupier]

Even if the Red Hat Developer sandbox gets updated to RHEL 9.0, wouldn't we be leaving users behind? maybe users that haven't got the latest RHEL or Fedora yet?

To avoid problems with native binaries, I think the solution which is more maintainable is to be able use the all-in-one jar. (for which there will be anyway issues with old RHEL 7 which can have extended support but on which Java 17 won't be provided and Java 17 will be required for Camel 4 in few months and kaoto backend is already requiring Java 20)

Also note the low usage of RHEL, from telemetry:

• RHEL users represents 0.0208% percent of VS Code Kaoto users
• RHEL users represents 0.701% percent of VS Code Camel related users

I do not think that we have the capacity to target more platforms than latest Linux, Windows and Mac.

[apupier]

VS Code XML hit the same issue of glibc problem. They are now building the native binaries of the XML Language Server with Ubuntu 20.04 (available on GitHub CI) and it seems to do the trick (they released today so we will see if it will cause any problems soon).
They are using Graalvm directly. To check that with Quarkus it will work too.