Release Notes and Known Issues
Release Notes and Known Issues for Red Hat CodeReady Workspaces 2.3
Robert Kratky
rkratky@redhat.com
Michal Maléř
mmaler@redhat.com
Fabrice Flore-Thébault
ffloreth@redhat.com
Yana Hontyk
yhontyk@redhat.com
devtools-docs@redhat.com
Abstract
Chapter 1. Release notes
Red Hat CodeReady Workspaces is a web-based integrated development environment (IDE). CodeReady Workspaces runs in OpenShift and is well-suited for container-based development.
This section documents the most important features and bug fixes in Red Hat CodeReady Workspaces. For the list of CodeReady Workspaces 2.3 release issues, see the Chapter 2, Known issues section.
-
To deploy applications to an OpenShift cluster from CodeReady Workspaces, users must log in to the OpenShift cluster from their running workspace using
oc login
. - Having multiple CodeReady Workspaces deployments on the same cluster is not recommended, and the ability to do so may be removed in a future release.
1.1. About Red Hat CodeReady Workspaces
Red Hat CodeReady Workspaces 2.3 provides an enterprise-level cloud developer workspace server and browser-based IDE. CodeReady Workspaces includes ready-to-use developer stacks for some of the most popular programming languages, frameworks, and Red Hat technologies.
This minor release of Red Hat CodeReady Workspaces is based on Eclipse Che 7.16.2 and offers a number of enhancements and new features, including:
- Operator available to all OSD 4.3 customers
- Support for Maven configuration injection in workspaces
- Support for OpenShift cluster-wide proxy configuration
- Improvements to workspace startup and overall performance
Languages updates
- Uses Java 11 instead of Java 8 in SpringBoot stack
- Java-related extensions updated to the latest version
- Dependency Analytics updated from 0.0.13 to 0.1.0
CodeReady Workspaces 2.3 is available in the Red Hat Container Catalog. Install it on OpenShift Container Platform, starting at version 3.11.
CodeReady Workspaces 2.3 is available from the OperatorHub in OpenShift 4.3 and beyond. CodeReady Workspaces 2.3 is based on a new Operator that uses the Operator Lifecycle Manager. This makes the CodeReady Workspaces installation flow simpler and doable without leaving the OpenShift Console.
To install CodeReady Workspaces for OpenShift 4.4 or later, get CodeReady Workspaces from the OperatorHub and follow the Installing CodeReady Workspaces on OpenShift Container Platform chapter of the Installation Guide.
To install CodeReady Workspaces for OpenShift 3.11, follow the instructions in the Installing CodeReady Workspaces using the CLI management tool on OpenShift Container Platform 3.11 chapter of the Installation Guide.
1.2. Notable enhancements
1.2.1. Support for asynchronous volume mounts added for workspaces
- A new type of storage with fast disk input/output that saves changes as in traditional persistent mode.
- Asynchronous storage is added to CodeReady Workspaces by a plug-in, which is automatically added to the workspace configuration if a user selects the asynchronous storage type.
- The plug-in initiates the restore command on workspace start and backs up all sources on workspace stop. Changes are periodically backed up while the workspace is running.
- This feature is currently only available for the Common PVC strategy.
1.2.2. Support for OpenShift cluster-wide proxy configuration
- Users can now configure a proxy for OpenShift clusters, the configuration of which is used by CodeReady Workspaces automatically.
- Operator automatically detects that OpenShift cluster-wide proxy configuration exists and uses it to configure its components.
-
Specifying an additional non-proxy host is possible by setting the
spec.server.nonProxyHosts
field in the CodeReady Workspaces custom resource (CR). The value of the CR is merged with the corresponding value of the OpenShift proxy configuration. Users can define or override OpenShift cluster-wide proxy configuration by setting a proxy in the CR.
Self-signed certificates for endpoints behind a proxy have to be added as a trust-store for CodeReady Workspaces to access them securely.
1.2.3. Support for OCP 4.5
CodeReady Workspaces 2.3 now supports OpenShift Container Platform 4.5.
1.2.4. New devfile for EAP XP 1.0 adds support for Microprofile applications development and debugging
This update provides CodeReady Workspaces support for a MicroProfile devfile. With this new devfile, users can easily develop and debug MicroProfile applications using EAP 7.3.1, launched directly from the Get Started page in CodeReady Workspaces. The required JBoss EAP XP image used by the devfile will be downloaded from Red Hat Container Catalog.
1.2.5. Specific namespace suggestion during Operator subscription to CodeReady Workspaces
The CodeReady Workspaces Operator now recommends the eclipse-che
namespace as the installation namespace. If this option is selected, the Operator automatically creates this namespace during the activation of the Operator subscription.
1.2.6. Improvements in connection stability
The connection to machine exec
and overall stability during che
task operations have been improved.
1.3. Other enhancements
1.3.1. A list of recently used workspaces available from Che-Theia
Users can find a new command in File → Open Recent Workspace that allows them to see a list of recently used workspaces from the IDE. For proper functionality, use Google Chrome.
1.3.2. Setting a maximum time for running workspaces
The custom resource property for hard timeout, che.limits.workspace.idle.hard.timeout
, adds the possibility to set a maximum time for running workspaces. After a specified number of minutes, a workspace is idled even if the checker detects workspace activity.
1.3.3. Server component migration to Java 11
Because of CodeReady Workspaces server migration to Java 11, CodeReady Workspaces server contributors will be able to use modern language features of Java 11 in future releases.
Additional benefits:
- Native container support
- TLS 1.3 support
- Language and performance improvements
- More minimalistic server image (20%)
1.3.4. Passing credentials in settings.xml now possible
Sensitive information such as passwords or configuration files can be mounted as Kubernetes secrets to remote Maven repositories.
1.3.5. Various plug-ins updated to latest versions
- update to redhat/dependency-analytics/0.1.0
- update to redhat/java/0.63.0 (and java8 and java11)
- update to redhat/quarkus-java11/1.5.0
- update to redhat/vscode-apache-camel/0.0.25
- update to redhat/vscode-camelk/0.0.15
- update to sonarsource/sonarlint-vscode/1.16.0
1.3.6. More memory for native compilation with Quarkus devfiles
The new limit for the memory was set to 4927 MiB.
1.3.7. Update for Java-based devfiles
Java-based devfiles have been migrated to use JDK 11 where possible, remove EAP if not required, and continue to use JDK 8 where needed. Since Maven 3.6 was moved into the JDK sidecar to support Quarkus, it is possible to use Quarkus with JDK 8 and 11 if a user sets up a custom devfile.
In addition, a new plugin-java8-rhel8
container replaces the previous stacks-java-rhel8
container and also provides support for Node.js and Python in the same container. This reduces the installation footprint for most devfiles and provides a single container for the most widely used languages.
1.3.8. Installing the CodeReady Workspaces Operator using the crwctl command-line tool
Only supported for OCP 3.11. For OCP 4, use the OperatorHub UI method.
1.3.9. Adding support for the Didact extension
Didact merges markup, such as Markdown and AsciiDoc, and provides an interactive link that makes it possible to use the markup in VS Code commands.
1.3.10. CloudShell editor removed
The CloudShell editor has been removed. However, it is still possible to create a CloudShell Workspace using an appropriate configuration in a standard devfile.
1.3.11. Metrics collection enabled by default for Operator CodeReady Workspaces installations
- CodeReady Workspaces server automatically exposes related metrics at a specific endpoint, allowing users to get to them without further action.
- OpenShift Cluster Monitoring is set to read the metrics from the exposed endpoint. This setup is enabled during the CodeReady Workspaces installation on OpenShift Container Platform.
1.3.12. An additional CLI endpoint allows users to open files from CLIs
Using the Che-Theia terminal, users can use the che
binary to call UI commands, such as File→Open File.
- This is possible to use with Bash scripts.
- For more information, see the Demo.
1.4. Supported platforms and installation methods
This section provides information about the availability of CodeReady Workspaces 2.3 on OpenShift Container Platform and OpenShift Dedicated, and about their supported installation methods.
Red Hat CodeReady Workspaces for OpenShift Container Platform can be installed on OpenShift Container Platform starting at version 3.11.
Table 1.1. Supported deployment environments for CodeReady Workspaces 2.3 on OpenShift Container Platform
3.11 | 4.4 | 4.5 | |
OpenShift Container Platform |
| OperatorHub | OperatorHub |
Table 1.2. Supported deployment environments for CodeReady Workspaces 2.3 on OpenShift Dedicated
4.3 | |
---|---|
OpenShift Dedicated | Add-On |
It is possible to use the crwctl utility script for deploying CodeReady Workspaces 2.3 on OpenShift Container Platform versions 4.4 and 4.5. This method is considered unofficial and serves as a backup installation method for situations where the installation method using OperatorHub is not available.
1.4.1. Installing and deploying CodeReady Workspaces
To install CodeReady Workspaces for OpenShift 4.4 or later, get CodeReady Workspaces from the OperatorHub and follow the Installing CodeReady Workspaces on OpenShift Container Platform chapter of the Installation Guide.
To install CodeReady Workspaces for OpenShift 3.11, follow the instructions in the Installing CodeReady Workspaces using the CLI management tool on OpenShift Container Platform 3.11 chapter of the Installation Guide.
1.4.2. Support policy
For Red Hat CodeReady Workspaces 2.3, Red Hat will provide support for deployment, configuration, and use of the product.
CodeReady Workspaces 2.3 has been tested on Chrome version 83.0.4103.97 (Official Build) (64-bit).
For more information, see CodeReady Workspaces life-cycle and support policy.
1.5. Difference between Eclipse Che and Red Hat CodeReady Workspaces
The main differences between CodeReady Workspaces and Eclipse Che are:
- CodeReady Workspaces is built on RHEL8 to ensure the latest security fixes are included, vs. Alpine distributions that take a longer time to update.
- CodeReady Workspaces uses Red Hat Single Sign-On (SSO) instead of the upstream project Keycloak.
- CodeReady Workspaces provides a smaller supported subset of plugins compared to Che. CodeReady Workspaces provides devfiles for working with other Red Hat technologies such as EAP and Fuse.
- CodeReady Workspaces is supported on OpenShift Container Platform and OpenShift Dedicated; Che can also run on other Kubernetes clusters.
Red Hat also provides licensing, packaging, and support, so CodeReady Workspaces is considered a more stable product than the upstream Eclipse Che project.
Chapter 2. Known issues
This section lists known issues with Red Hat CodeReady Workspaces 2.3. Where available, workaround suggestions are provided.
2.1. OpenShift does not support a deploying applications made from Java Spring Boot devfile workspace
When a user wants to test an application created in the Java Spring Boot devfile workspace by deploying it to OpenShift, an error message during the application deployment interrupts the process:
Execution fmp of goal io.fabric8:fabric8-maven-plugin:3.5.40:build failed: No <dockerHost> given, no DOCKER_HOST environment variable, no read/writable '/var/run/docker.sock' or '//./pipe/docker_engine' and no external provider like Docker machine configured
2.2. Adding registries manually using Theia Plugin View does not reflected in the View automatically
To work around this issue, refresh the page of the browser using F5 or Ctrl-r on macOS.
2.3. Using a different username than the OpenShift username, when users do not have the privileges to create namespaces, breaks a workspace start
Applies for situations when an administrator wants to restrict users' privileges to create namespaces and pre-create them before the CodeReady Workspaces installation.
To work around this issue, use the OpenShift username when logging into CodeReady Workspaces.
2.4. AirGap installation of CodeReady Workspaces 2.3 does not work on OpenShift 4.4
On OpenShift 4.4, the catalog bundle image is corrupted and does not appear in OperatorHub. To workaround this issue, update to OpenShift 4.5.
2.5. Installing CodeReady Workspaces using crwctl server:start
fails in clusters with multiple CodeReady Workspaces deployments
Installation of CodeReady Workspaces, using the crwctl server:start
with OpenShift OAuth, fails or does not deploy resources if existing resources from another crwctl installation exist in the cluster.
To workaround this issue, delete old resources and perform a fresh installation. For instructions, see step 6 of the Installing CodeReady Workspaces on OpenShift 3 using the Operator Installation Guide chapter.
Having multiple CodeReady Workspaces deployments on the same cluster is not recommended, and the ability to do so may be removed in a future release.
2.6. Dashboard Certificate Error warning refers to an incorrect location
When CodeReady Workspaces deployed on OpenShift encounters a certificate error, the error notification links to the wrong remediation instructions.
To import the certificates, see: Installing Codeready Workspaces in TLS mode with self-signed certificates
2.7. Some run and build commands of the The Getting started
examples may fail in the AirGap installations
Some of the sample projects included in the Getting Started devfiles are not designed for offline or airgapped use, so some commands may not work. To resolve this, user may have to talk to a organization’s administrator to get access to internal mirrors, such as NMP, Maven, and PIP.
The base functions of the Getting started
ZIP-archived samples embedded in the offline devfile registry do not work.
Commands that require internet access to run: Run
, Simple build `, `Outline
2.8. PHP language server marks valid imports as erroneous in PHP-DI devfile
Workspaces created from the PHP-DI
devfile incorrectly highlight valid code as erroroneous.
To work around this issue:
2.9. crwctl workspace
commands fails in workspaces with OpenShift OAuth
The crwctl workspace:inject
command causes the following error during the workspace Pod localization in workspaces created with OpenShift OAuth support.
$ crwctl workspace:inject -k -n workspaces-server › Current Kubernetes context: 'workspaces-server/api-che-devex-devcluster-openshift-com:6443/system:admin' › Error: Authentication is enabled but 'access-token' is not provided. › See more details with the --help flag.
To work around the issue, use the oc login
command inside the affected container instead.
Other failing commands:
-
crwctl workspace:list -n workspaces-server --access-token="${TOKEN}"
-
crwctl workspace:inject -k -n workspaces-server --access-token="${TOKEN}"
- CRW-803
2.10. The workspace sharing does not work
The File > Share
IDE command currently launches the Workspace
tab, but the Share
tab is missing.
2.11. The crwctl server:delete
command breaks existing CodeReady Workspaces deployments on the same OpenShift cluster
The crwctl server:delete
command removes certain cluster-scoped objects, which causes all other CodeReady Workspaces deployments to terminate unexpectedly.
To work around the issue, patch the Custom Resource Definition:
+
$ oc patch customresourcedefinition/checlusters.org.eclipse.che -p \ '{ "metadata": { "finalizers": null }}' --type merge
Having multiple CodeReady Workspaces deployments on the same cluster is not recommended, and the ability to do so may be removed in a future release.
2.12. The crwctl server:delete
command incorrectly removes checluster
from all CodeReady Workspaces projects on OpenShift Container Platform
Instead of removing checluster
from the current CodeReady Workspaces project, the checluster
is deleted from all projects in the OpenShift Container Platform cluster.
2.13. Deleting a checluster
custom resource causes CodeReady Workspaces Operator errors
Uninstalling the CodeReady Workspaces manually by deleting the checluster
custom resource in the OperatorHub causes errors in the CodeReady Workspaces Operator. As a consequence, attempting to re-install CodeReady Workspaces in OperatorHub fails.
2.14. OpenShift Connector plug-in requires manually connecting to the target cluster
By default, the OpenShift Connector plug-in logs in to the cluster as inClusterUser
, which in some cases does not have the manage project
permission. This causes an error message to be displayed when creating a new project 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.
2.15. Error highlighting and code completion do not work in a Go devfile
To work around this issue, update the Go language server plug-in to the latest version.
2.16. Creating a namespace fails when a login name with unsupported characters is used
If the <username>-che
namespace strategy is used, a problem can occur with the user names that contain characters incompatible with the Kubernetes namespace name pattern.
The specified namespace example@redhat.com-codeready is invalid: a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name', or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')
To work around this issue, do one of the following:
-
Use the
CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT
property with <userid> or <workspaceid> instead of <username> . Use the
CHE_INFRA_KUBERNETES_NAMESPACE_ALLOW_USER_DEFINED
property to allow users to select namespaces by themselves.
2.17. Using of NFS mounts may cause installation or workspace startup failures
For best performance, Red Hat recommends using block storage for Persistent Volumes used with CodeReady Workspaces. The use of NFS is not recommended.
2.18. CodeReady Workspaces deployed without TLS support causes some features to not work properly
In CodeReady Workspaces 2.1 and later, secure HTTPS is required to use the most recent Theia IDE, and therefore TLS mode is enabled by default. Disabling the TLS support will cause user experience to suffer and some UI will not work as expected or at all.
For example, the welcome page may be blank or broken, images may be missing, and other functionality may not work properly.
2.19. CodeReady Workspaces fails to shut down after executing crwctl server:stop
The crwctl server:stop
command 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.
Chapter 3. FAQ
Can I install CodeReady Workspaces offline (that is, disconnected from the internet)?
Yes, you can. For detailed instructions, see Installing CodeReady Workspaces in restricted environments chapter of the Installation Guide.
Can I use non-default certificates with CodeReady Workspaces?
Yes, you can use self-signed or public certificates. See Installing CodeReady Workspaces on OpenShift v3 chapter of the Installation Guide.
Can I run multiple workspaces simultaneously?
Yes. The following two conditions must be met to run multiple workspaces simultaneously:
-
CodeReady Workspaces must use the
per-workspace
Persistent Volume Claim (PVC) strategy (default), and Persistent volumes (PVs) must use
ReadWriteMany
(RWX) access mode.Thus to run multiple workspaces simultaneously, ensure the following configuration is set:
-
Set
ReadWriteMany
(RWX) access mode for PVs. -
Use the
per-workspace
PVC strategy (default in CodeReady Workspaces), or optionally, theunique
strategy.
-
CodeReady Workspaces must use the