| Re: [che-dev] Switch to the DevWorkspace operator as Che workspace engine |
_______________________________________________Hi all,
After more than one year of work, and after introducing it as an experimental option in Che 7.28, we are close to permanently switching to the new workspace engine.
The change will happen at the beginning of the next sprint in the main branch and will land in v7.42 of Che (planned for the 12th of January).
## 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: https://github.com/eclipse/che/issues/20830
The initial architectural documentation: https://github.com/eclipse/che/issues/15425
Milestones that led to v7.42: https://github.com/eclipse/che/issues/17307
A couple of blog posts related to the new engine (more are coming in the next weeks):
https://che.eclipseprojects.io/2021/06/23/@florent.benoit-devfile-v2-and-ide-plug-ins.html
Devfile v2 website: https://devfile.io/
DevWorkspace Operator: https://github.com/devfile/devworkspace-operator
(7.)42 is the answer :-) https://simple.wikipedia.org/wiki/42_(answer)
Kudos to the whole Che team that worked hard on this challenging pivot 💪
We hope you will love it,
Mario
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev