Major Enhancements
Switch to the DevWorkspace Operator as workspace engine
The stable channel of Che operator has the DevWorkspace enabled by default and use the operator "all-namespace" installation mode. The other channels are being deleted. After more than one year of work, and after introducing it as an experimental option in Che 7.28, we have switched to the new workspace engine. 🎉
Why are we doing this?
Scalability and HA
The new engine is a Kubernetes controller. As such it runs behind the kube-apiserver that is designed to scale horizontally. The data is persisted in a key value store designed to be highly available (etcd).
A universal API
Workspaces are Kubernetes object:
- Kubernetes clients such as kubectl or the OpenShift console can manage them
- They are secured via RBAC
- They can be validated and protected by admission webhooks
- The devfile specification is automatically generated from the API
A simpler design
The new workspace engine has a single responsibility that is to manage workspace resources. It's decoupled from the developers IDEs and from the server side components of Che. Communications between components happens asynchronously using ConfigMaps and Secrets rather than a REST API.
A refactoring opportunity
The new engine has been written from scratch and we took the opportunity to address legacy issues:
- Simpler configuration of the Che operator
- No hard dependency on Keycloak but any OIDC provider can be used for authentication
- Introduction of a single gateway to simplify the network model and the TLS certificates management.
What's changing?
For an admin
- Deploying Che is simpler because there are less configuration options. For instance the namespace strategy and the exposure strategy are set to "per-user" and "single-host" respectively as we have observed that that’s what users want anyway.
- Che can be linked to any OIDC provider to enable authentication. We are not tied up to Keycloak anymore and Dex is deployed by default on minikube.
- Deploying multiple instances of Che on the same cluster is not possible anymore. That will avoid problems due to conflicting versions of Che running on the same cluster.
For a user
- Workspaces use Devfile v2 that has some significant improvements compared to v1 as parents and events.
- Devfiles are IDE agnostic and don't include plugins definitions anymore. IDE specific configurations are managed in separate files as VS Code extensions.json.
- Some redundant getting started samples have been removed.
- Workspaces IDEs don’t run in an iframe anymore
Should I upgrade to v7.42 as soon as it is released or should I wait?
It's ok to deploy v7.42 in the case of a first installation of Che or for a non-production environment. You will benefit from the new features right away.
You should wait if instead you are an existing user and you don’t want to lose existing workspaces data. For existing users we recommend waiting for v7.44 of Eclipse Che, when we plan to release an automated workspace migration functionality.
More Links
Finally here are some links to learn more about the new feature:
- The endgame plan
- The initial architectural documentation
- Milestones that led to v7.42
- A couple of blog posts related to the new engine (more are coming in the next weeks):
- Devfile v2 website
- DevWorkspace Operator
- (7.)42 is the answer :-)
Kudos to the whole Che team that worked hard on this challenging pivot 💪
Dashboard should be be able to group samples in dedicated group
The samples in the user dashboard are labelled as community .For downstream version of Che samples are labelled
tech-preview.
Plugins updates
No update during this sprint