Proof of concept working in Eclipse Che with Code Server #102
Comments
apupier
changed the title
apupier
changed the title
|
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 |
|
was there a specific reason why we require RHEL 9 on backend side, @Delawen ? |
|
for reference, there is this kind of error: 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. |
|
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: |
|
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 only able to run the current released version working. It would be good to explore possibilities of running the dev version.
|
|
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.
What is the problem with the snapshot version? |
|
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. |
|
Still not working in Red Hat developer sandbox 😞 |
|
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. |
it is possible: #89
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:
I think better paths to support Kaoto in Red Hat Developer sandbox are either:
|
|
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:
I do not think that we have the capacity to target more platforms than latest Linux, Windows and Mac. |
|
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). |
|
the basics are working
closing this issue, if we find specific issue we can open a specific ticket. If we want to suppor tit we will need to provide automated tests too. |
It would be nice to have the extension working in Eclipse Che with Code server
The text was updated successfully, but these errors were encountered: