Red Hat CodeReady Workspaces 2.1 provides an enterprise-level cloud developer workspace server and browser-based integrated development environment (IDE). CodeReady Workspaces includes ready-to-use developer stacks for most of the popular programming languages, frameworks, and Red Hat technologies.

This minor release of Red Hat CodeReady Workspaces is based on Eclipse Che 7.9 and offers a number of enhancements and new features, including:

CodeReady Workspaces 2.1 is available in the Red Hat Container Catalog. Install it on OpenShift Container Platform, starting at version 3.11, by following the instructions in the Installing CodeReady Workspaces chapter of the Installation Guide.

From OpenShift 4.1, CodeReady Workspaces 2.1 is available from the OperatorHub. Based on a new Operator that uses the Operator Lifecycle Manager, the installation flow is simpler and can be handled without leaving the OpenShift Console.​

For OpenShift 4.3, get CodeReady Workspaces from the OperatorHub and follow the Installing CodeReady Workspaces on OpenShift 4 from OperatorHub chapter of the Installation Guide.

The main difference between CodeReady Workspaces and Eclipse Che is that CodeReady Workspaces is supported by Red Hat. There is no difference in the technologies these two products use. Nevertheless, CodeReady Workspaces runs the plug-ins and devfiles from supported images. Licensing, packaging, and support are also provided by Red Hat.

The following table lists the differences between Eclipse Che and Red Hat CodeReady Workspaces:

Users with the cluster-admin role who use OpenShift 3.11 may experience the 2.0 version java-eap-maved-based workspaces with TLS and OpenShift OAuth support fail to start after the product server is updated to version 2.1.1. Users are then not permitted to access the old Persistent Volume.

To work around this issue, create a new 2.1.1 workspace using the same devfile that was used to create the workspace in the previous version.

By default, the Openshift Connector plug-in logs into the cluster as inClusterUser, which may not have the manage project permission. This causes an error message to be displayed when a new project is being created using Openshift Application Explorer:

Failed to create Project with error 'Error: Command failed: "/tmp/vscode-unpacked/redhat.vscode-openshift -connector.latest.qvkozqtkba.openshift-connector-0.1.4-523.vsix/extension/out/tools/linux/odo" project create test-project ✗ projectrequests.project.openshift.io is forbidden

To work around this issue, log out from the local cluster and relog in to OpenShift cluster using the OpenShift user’s credentials.

Absence of the debug configuration, situated in the debug panel of a created workspace, when the Node JS Config Map devfile is used for a new workspace creation.

The dedicated crwctl command crwctl server:stop is unable to shut down the CodeReady Workspaces server and instead fails with a timeout and displays the following error message:

›   Error: E_SHUTDOWN_CHE_SERVER_FAIL - Failed to shutdown CodeReady Workspaces server. E_CHE_API_NO_RESPONSE - Endpoint: http://codeready-ndp-test.apps.crw.codereadyqe.com/api/system/stop?shutdown=true - Error message: timeout of
 ›   3000ms exceeded

To work around the issue, execute crwctl server:stop again.

The crwctl workspace:inject command causes the error during the workspace Pod localization in workspaces created with OpenShift OAuth support.

$ crwctl workspace:inject -n codeready-tls-oauth -k
  ✔ Verify if namespace codeready-tls-oauth exists
  ✖ Verify if the workspaces is running
    → No workspace pod is found
    Injecting configurations
 ›   Error: No workspace pod is found

To work around the issue, use oc login command inside the affected container instead.

When a workspace has been created in a dedicated namespace that is later entirely deleted, the corresponding OpenShift project needs to be removed manually to complete the deletion process.

To work around the issue: delete the remaining empty project from the OpenShift console:

$ oc delete project <projectname>

After using the crwctl server:delete command, the OpenShift project that used to host the CodeReady Workspaces instance remains. This makes it impossible to install a new CodeReady Workspaces instance into the default namespace, which still exists. To uninstall CodeReady Workspaces completely, manually remove the namespace.

To work around the issue:

Creation of the CodeReady Workspaces cluster, codeready-workspaces, in a namespace can be affected by previous use of the crwctl server:delete uninstallation command.

To work around the issue:

An embedded application of the Java EAP Maven stack in the debug mode tends to fail. The dialog window with application URL is already displayed, but the application, according to the terminal output, is still starting. The use of the URL link displayed leads to an error.

Attempting to restart a workspace and re-enter it fails, and an error message is displayed instead. To work around this issue, restart the workspace again.

The Workspace Cap and Workspace RAM cap functions, which control the maximum number of workspaces for an organization and the maximum RAM that organization workspaces can use, currently do not work.

Devfiles contain a set of predefined commands that can be executed in workspaces started using devfiles from the devfile registry. However, when a command defined by a devfile is executed from the workspace, the terminal, in which the commands normally run, does not open.

The work around this issue, do not open the same workspace link in two different browsers.

Due to CodeReady Workspaces and OpenShift OAuth integration, workspaces are not stopped by the idling timeout, when the workspace is located in a user’s Pod.

To work around this issue, disable the stopping of idling workspace by timeout feature for the workspaces with OpenShift OAuth integration:

$ oc patch checluster/eclipse-che --patch "{\"spec\":{\"server\":{\"customCheProperties\": {\"CHE_LIMITS_WORKSPACE_IDLE_TIMEOUT\": \"-1\"}}}}" --type=merge -n che

To workaround this issue, update the Go language server plug-in to the latest version.

In workspaces based on the Go devfile, an error notification is displayed during the start of the Debug current file configuration.

To work around this issue, execute the predefined Run current file command first, then repeat the debugging procedure.