💾 Archived View for yujiri.xyz › software › che.gmi captured on 2022-06-03 at 23:20:37. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Eclipse Che is the worst piece of software I have ever seen, likely the worst that exists. It's worse than Windows, worse than PHP, worse than systemd, worse than twitter.com, worse than anything made by Intuit. It is absolutely *nothing* but egregious flaws, absolutely nothing good can be said of it.
Intuit has shitty software engineering
The sheer horror of this software starts with its very premise. What is Eclipse Che? It is a way to run a web-based IDE on a Kubernetes cluster.
What???
If that sentence doesn't make you say "what the fuck", please stop programming.
My background with Che comes from using it as a contractor at a startup trying to make a web service that uses a Kubernetes cluster. The web service's point is basically to give out exercises to job candidates that are more realistic than the industry status quo; the web service sets up a container on the Kubernetes cluster and asks the candidate to SSH into it and complete a challenge. This worked, it was great, however boss decided that replacing the SSH login with an in-browser IDE would have more "wow factor", and Che was chosen for this.
Incase you thought I meant that Che just runs in *a* container on a Kubernetes cluster: no. It spans an entire federation of containers: a server pod, a gateway pod, an operator pod, a Postgres pod, a pod for the plugin registry, a pod for the devfile registry, a pod for the web interface, and a pod named "che-tls-job-*", that changes status to Completed but sticks around forever crowding your kubectl output even if you run `chectl server:delete` (which means that when you iterate, che-tls-jobs accumulate).
It even relies on stuff outside of the eclipse-che namespace in your cluster. It has to have a separately installed *ingress*; our kubernetes distribution, k3d, sets up an ingress called traefik by default, but that didn't work because Che was set to expect something called ingress-nginx to be installed on the cluster. And there is no documentation about that expectation. It just requires that and you have to figure out that you're supposed to install the ingress-nginx plugin.
We tried configuring it to use the traefik ingress. However that led to Che using a directly self-signed cert instead of a cert signed by a certificate authority, which meant the instructions given by chectl output for importing its certificate authority into a browser didn't work; we had to whitelist each of the many domains it uses manually. It also led to some errors creating workspaces that I don't remember. In short it doesn't work with the default traefik ingress and we had to use ingress-nginx. (Why that has *any* effect on the cert it uses, I don't fucking know.)
The delete command also doesn't remove the user namespace (eg. admin-che), which is separate from the eclipse-che namespace (I wonder what happens if you have a user named eclipse?), and I've seen this cause problems before where the cluster is in some invalid state and the delete command doesn't fix it, I have to also delete the admin-che namespace.
Che is designed to force the use of an *external identity provider* using a protocol called OpenID Connect. In theory you could configure it so you log in to Che with Google, I guess, if you wanted to bootlick oligopolies and give them even more power. I say "in theory" because in practice nobody could figure out how to get this software to actually work.
What if you just want a simple setup where you manage the accounts yourself? Absolutely not, not supported. You *must* use an OIDC provider. Older versions of Che came with a builtin instance of Keycloak, a self-hostable OIDC provider. However newer versions don't have it and you would have to set up Keycloak yourself to use them - and Keycloak is itself a behemoth of complexity and poor documentation that you'll spend a week trying to set up, believe me I tried.
Thus, we had to roll back to an older version - v7.41.2 - for our use case, which has the builtin Keycloak.
Oh, and the latest version when we started was v7.46.0. Notice what that means? They're using semver wrong! They made a huge breaking change without incrementing the major version! This is made even worse by... something I'll get to.
The whole thing is barely documented. Their web documentation leaves a lot to be answered, and there are pages in the old version of it that have no equivalent in the new version and so redirect to something irrelevant when you try to view the latest version.
A deployed Che instance has a page you can visit with Swagger docs on the API for controlling workspaces. However, *in v7.41.2*, it *only documents *the new devworkspace* API that isn't even enabled by default in v7.41.2, and not the older *workspace* API that this version actually uses*. So that was useless to me. I couldn't find any documentation on the old API anywhere; apparently they deleted all trace of it from the web even though this version is *only 3 months old*. I had to reverse engineer the API.
Oh yeah and sure I tried to enable devworkspaces so we could use the documented API. I couldn't. Apparently that requires a bunch of special extra configuration that isn't documented anywhere.
I also saw plenty of banal bugs. For example, when I create a workspace, it immediately says "Error: workspace failed to start" as it starts the creation process. And there's a place you can see logs from the creation process, but after my first few days with this software it mysteriously stopped working - the logs are just always empty. After another few days it started working again.
The "New File" button in the IDE just does nothing for me.
When signing in through the included Keylcoak instance, the forgot password page includes the text `<br/>`.
This one is so horrifying I felt like I'd have trouble even getting my boss to believe me when I started seeing the symptoms. In fact, let me tell you the symptoms first:
Bizarre, right? Feels like being gaslit. Let me link the issues I made about this:
https://github.com/che-incubator/chectl/issues/2027
https://github.com/eclipse/che/issues/21366
That's fucking right: **Eclipse Che secretly self-updates to incompatible versions while running.**
Holy fucking shit! Can you even believe that?
And let me add that whenever you run a chectl command with an older version it warns you and asks you if you want to update. But it does this even if you say no to that question!
chectl reads your terminal width and does some dastardly homecooked stuff with it. When showing the message `Documentation how to add a CA certificate into a browser: https://www.eclipse.org/che/docs/che-7/end-user-guide/importing-certificates-to-browsers/`, it inserts its own line-breaks, which has two consequences:
An even worse thing it does with some other output (no, it doesn't even treat all output the same way), such as messages explaining why your Che configuration is invalid, is *actually truncate the message at one line* so you simply can't see why your configuration is invalid. And yes, the message I saw this with was too long to fit even in a full-screen terminal with a small font size.
Jesus guys, terminals handle line breaks so you don't need to do any of that shit! You literally don't have to do anything to get this to behave right, just *don't go out of your way to break your software!*
There are also some appalling issues with their support for custom branding. While it's completely unfair to ask for free software to add support for corporate users to deny them a mere attribution, they did decide to add such features, so I think issues with those features are a fair example just of how bad their software engineering is.
They don't really explain why it's necessary to build their plugin registry repository; the answer is just to get the YAML file that describes the spec for the IDE container. And there's issues with the procedure for building the plugin registry repository itself - they really only considered the most mainstream use case. For example, I was trying to build it with a docker registry that is only served over HTTP, so I put in my registry address as they show, and got confusing error messages because apparently only HTTPS registries are supported and they just assume you know that. Eventually what I had to do was build it with *their* registry, then manually edit the YAML file.
And if your product.json has certain fields empty, such as the icon or logo images, it just silently ignores your product.json and reverts to the default branding. There is no documentation about that.
See that comment on the links field in the product.json, that says "Use tags to group links to make them easier to find."? It doesn't say what that means, what are "tags" and how can you use them. There are no other occurrences of that word in the document.