Release Notes and Known Issues
Release Notes and Known Issues for Red Hat CodeReady Workspaces 2.8
Michal Maléř
mmaler@redhat.com
Robert Kratky
rkratky@redhat.com
Fabrice Flore-Thébault
ffloreth@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.8 release issues, see the Chapter 3, 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.
- For best performance, use block storage for Persistent Volumes used with CodeReady Workspaces.
-
The name of the default CodeReady Workspaces namespace is openshift-workspaces. A user who wishes to use the previous name for the default namespace,
workspaces
, needs to note that documentation was updated to reflect the current state. - For IBM Power Systems (ppc64le), the memory limit for some plug-ins has been increased by up to 1.5G to allow pods sufficient RAM to run. For example, on IBM Power Systems (ppc64le), the Che-Theia editor pod requires 2G; the OpenShift connector pod requires 2.5G. For AMD64 and Intel 64 (x86_64) and IBM Z (s390x), memory requirements remain lower at 512M and 1500M respectively.
1.1. About Red Hat CodeReady Workspaces
Red Hat CodeReady Workspaces 2.8 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.28 and offers a number of enhancements and new features, including:
- Improvements to workspace start and overall performance
Bug fixes, such as:
-
Creating a workspace using the
redhat/vscode-yaml
plug-in does not work - The Topology view does not respect CodeReady Workspaces icon on OpenShift Container Platform 4.6
- Debug stops at the breakpoint only if breakpoint set up during debug session in a Quarkus workspace
- Cannot install plugin from plugins list
- VS Code extensions providing code snippets APIs are not usable
- Plug-ins list is empty
- Unable to checkout repository to a different branch
-
The
Install dependencies
command fails in the PHP-DI workspace - Sonarlint does not work
- Broken connection status service for Che-Theia
- Installation with router sharding not working
-
Creating a workspace using the
Plugin and Devfile Registry Updates
Language updates
- VS Code Camel support updated to 0.0.31: See: CRW-1629
Plug-in updates
- VS Code Camel K plug-in updated to 0.0.23
- VS Code TypeScript plug-in updated to 1.49.3
- VS Code Sonarlint plug-in updated to 1.20.1
CodeReady Workspaces 2.8 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 on OpenShift Container Platform 3.11 chapter of the Installation Guide.
CodeReady Workspaces 2.8 is available from the OperatorHub in OpenShift 4.6 and beyond. CodeReady Workspaces 2.8 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.6 or later, get CodeReady Workspaces from the OperatorHub and follow the Installing CodeReady Workspaces on OpenShift 4 from OperatorHub chapter of the Installation Guide.
1.2. Notable enhancements
1.2.1. New CodeReady Workspaces dashboard
A new dashboard delivers a more streamlined user experience, faster loading, and more consistent interface design with Red Hat OpenShift. The dashboard is based on PatternFly, Red Hat’s open source design system, and will continue to evolve over the coming releases.
1.2.2. Support of OpenShift OAuth flow for factories from private repositories using Dashboard
Dashboard now performs additional actions required by the Che server during OpenShift authentication flow for factories from private repositories.
This allows a user to accept a factory from a private repository using a Dashboard request to resolve factory details from a repository URL provided by the user (POST /api/factory/resolver).
Che server then recognizes that URL points to a private repository and looks there for credentials secret. If no secret is present, the Che server initiates the automatic OAuth login procedure.
1.2.3. Simplified Factory URL identificator
The previously used /f?url=
attribute for identifying Factory locations is now changed to the #
character. Users can now use the <user-ocp-provider>#<factoryURL>
rather than <user-ocp-provider>/f?url=<factoryURL>
. The links made using the previous way will remain operational.
1.2.4. Automatic plug-in recommendation for the workspaces that start without a devfile
For workspaces that start without a devfile, a list of recommended plug-ins will be created during the Factory handling. A user will be prompted by a CodeReady Workspaces to install them and do workspace restarts for their activation.
1.2.5. Support for Project Lombok
Lombok is a popular Java IDE extension available for VS Code, which automatically plugs into a user editor and builds the needed tools to enhance the written Java code.
1.2.6. Support sidecar filesystem access for VS Code extensions
Cross-container file system access between Che-Theia editor and VS Code extensions is now possible. Users can now access files between containers, making it easier to share build assets.
1.2.7. Devfile switch for Single-root/Multi-root mode
Many VS Code extensions require to be run in Multi-root mode. CodeReady Workspaces is currently still in the Single-root mode by default, but the ability to switch for the Multi-root has been added into a devfile. With upcoming releases, the aim is to set the Multi-root mode as the default for CodeReady Workspaces, followed by Single-root mode disablement.
For turning on the Multi-root mode, use the multiRoot
attribute property in a workspace devfile.
attributes: multiRoot: 'on'
1.2.8. Support for installation in restricted environments on IBM Z
Installation in a restricted environment is now supported on OpenShift Container Platform on IBM Z infrastructure. This will ensure that workspaces can be started without relying on resources from outside networks.
1.3. Other enhancements
1.3.1. Enhancements to Bitbucket support
This release improves the workflow and automates all authentication actions to eliminate manual credential configuration.
- BitBucket and CodeReady Workspaces integration is authorized using the OAuth 1 protocol.
Following actions are now automated:
- Direct login redirection.
- Request for personal access token creation using BitBucket REST API.
- Storing of authentication tokens in user’s namespace for further usage.
- CRW-1490
1.3.2. Enhancements to workspace-plugin
and ssh-plugin
Che-Theia built-in plug-ins
-
workspace-plugin
handles Git operations at workspace start, calling thessh-plugin
when encountering an SSH issue. -
ssh-plugin
manages SSH keys and provides an API, allowing other plug-ins to handle SSH-related operations, such as operating with SSH keys.
This update allows these plug-ins to handle authentication events during a Git project cloning using SSH URI, such as secure login to a Git repository.
In a case of an interaction with a GitHub repository, workspace-plugin
can use ssh-plugin
to:
- Upload of a user public key.
- Suggest addition of an auto-generated key to the Git repository manually.
- Allow a user to use their custom TLS certificate.
- Issue 13494
1.3.3. Resource limits and requests for devfiles and plug-ins
The already existing possibility to set resource limits and request for devfiles and plug-ins, which was added to improve the cluster resources management, was enhanced by updating all plug-ins to have a capability to set these values.
- For the sake of preserving these values, plug-ins resource limits were moved from devfiles to plug-ins directly.
- Resource limits were added to all sidecar plug-ins.
- CRW-1637
1.3.4. Support for the use of contributors' snippets
CodeReady Workspaces now supports the ability for VS Code extensions running in sidecars to load contributed snippets.
These code snippets act as a valuable productivity tool for developers, allowing them to use a collection of standard code patterns that would have been otherwise copied from reference manuals.
1.3.5. Support for GitLab repository URLs within factory links
A user can now create a CodeReady Workspaces workspace using a factory link containing a GitLab repository URL.
Chapter 2. Installing and deploying CodeReady Workspaces
For OpenShift 3.11, see the Installing CodeReady Workspaces on OpenShift Container Platform 3.11 chapter of the Administrator Guide.
For OpenShift 4.7, see the Installing CodeReady Workspaces from Operator Hub chapter of the Installation Guide.
2.1. Supported deployment environments
This section describes the availability and the supported installation methods of CodeReady Workspaces 2.8 on OpenShift Container Platform 4.6, 3.11, and OpenShift Dedicated.
Table 2.1. Supported deployment environments for CodeReady Workspaces 2.8 on OpenShift Container Platform and OpenShift Dedicated
Platform | Architecture | Deployment method |
OpenShift Container Platform 3.11 | AMD64 and Intel 64 (x86_64) |
|
OpenShift Container Platform 4.6 | AMD64 and Intel 64 (x86_64) |
OperatorHub, |
OpenShift Container Platform 4.6 | IBM Z (s390x) |
OperatorHub, |
OpenShift Container Platform 4.6 | IBM Power Systems (ppc64le) |
OperatorHub, |
OpenShift Container Platform 4.7 | AMD64 and Intel 64 (x86_64) |
OperatorHub, |
OpenShift Container Platform 4.7 | IBM Z (s390x) |
OperatorHub, |
OpenShift Container Platform 4.7 | IBM Power Systems (ppc64le) |
OperatorHub, |
OpenShift Dedicated 4.7 | AMD64 and Intel 64 (x86_64) | Add-On |
Support for deploying CodeReady Workspaces on OpenShift Container Platform on IBM Z (s390x) and IBM Power Systems (ppc64le) is currently only available as a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For details about the level of support for Technology Preview features, see Technology Preview Features Support Scope.
2.2. Support policy
For Red Hat CodeReady Workspaces 2.8, Red Hat will provide support for deployment, configuration, and use of the product.
CodeReady Workspaces 2.8 has been tested on Chrome version 90.0.4430.72 (Official Build) (64-bit).
For more information, see CodeReady Workspaces life-cycle and support policy.
2.3. 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 (RH-SSO) instead of the upstream project Keycloak.
- CodeReady Workspaces provides a smaller supported subset of plug-ins 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 3. Known issues
This section lists known issues with Red Hat CodeReady Workspaces 2.8. Where available, workaround suggestions are provided.
3.1. Misleading error message for a workspace failure caused by the mkdir
Pod timeout
The failure caused by a lack of OpenShift Container Platform cluster resources is accompanied by a misleading error message:
Your session has expired. Please, log in to CodeReady Workspaces again to get access to your OpenShift account.
This message will be fixed in the upcoming release.
To work around the issue caused by the mkdir
Pod timeout, provide more resources to the OpenShift Container Platform cluster.
3.2. Workspaces do not reload after a plug-in installation
A restart of a workspace initialized with the Click here to apply changes and restart your workspace button fails to reload the workspace after a plug-in installation.
To work around this issue, start the workspace manually.
3.3. CodeReady Workspaces 2.7 Node.js workspaces fail to start after migration to the latest version
To work around this issue:
- Open a devfile of the affected workspace using Dashboard and the Devfile tab.
Replace the
id
of thecomponents
property with the following:components: - id: vscode/typescript-language-features/latest
3.4. Unability to rename the metadata.name
property for an existing devfile
When pasting yaml into the devfile editor to change an existing workspace, make sure not to overwrite the value of metadata.name
as this will prevent you from saving your changes and an SQL error will be shown instead.
3.5. Resource Monitor plug-in cannot access the workspace Pod
Resource Monitor plug-in placed in Status Bar fails to reach the workspace Pod and displays an error message notification for all Devfile workspaces.
3.6. Some API calls stop working when a user is logged off from CodeReady Workspaces for more than a day
If a user did not log in to a CodeReady Workspaces instance for a period longer than the expiration period of an OpenShift token, which is one day, some API calls stop working, and a user can not reuse them.
As a temporary workaround, a user can log in to CodeReady Workspaces using a web browser and enable API calls functionality for another day.
3.7. A workspace IDE is not loading when the workspace PVC is used to its maximum limit
An inability to load the keycloak.js
JavaScript file when the Persistent Volume Claims (PVCs) of a workspace operate on their maximum limit. As a consequence, the IDE cannot start properly with the workspace.
This issue occurs in CodeReady Workspaces workspaces with a disabled OpenShift OAuth service combined with the Common PVC strategy.
3.8. Debug configuration is not displayed in the Debug view
A problem related to file watchers infrequently occurs, causing a disability to start a debug session because of the missing debug configuration in the Debug view.
To work around this issue, open the /projects/.theia/launch.json
file and use the configuration file, which will now be present in the Debug view.
3.9. Missing preinstalled language server tools for GO workspaces
The absence of additional tools causes a feature, such as Auto-complete, to fail in a workspace created using the default GO devfile.
To work around this issue in a non-restricted environment installation, install the required module using the Install button of the pop-up window in the IDE.
3.10. Rare workspace startup failures
Infrequently, CodeReady Workspaces workspaces fail at the start when multiple workspaces are started in a cluster simultaneously. The issue affects less than 1% of all workspaces started.
3.11. Inability to request a JSON response from OpenShift client
Attempts to obtain a JSON response request from OpenShift client fails and are accompanied by a warning message in the Red Hat Single Sign-On Pod.
WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-138,ejb,ycloak-598b6c57b4-khhfb) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:883#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@792525a5] for cluster [ejb], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods ]]
3.12. Inability to edit a Red Hat Single Sign-On user account
After logging in to Red Hat Single Sign-On, a user is not able to edit an account profile using the Manage account tab.
3.13. Some run and build commands of the The Getting started
examples may fail in restricted environment installations
Some of the sample projects included in the Getting started section are not designed for a use in restricted environments, 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
3.14. Wrong default value for a Quarkus project default folder
Instead of suggesting /projects/
as the default target folder of the Quarkus sample project, the Create Quarkus project button of the Quarkus wizard suggests the root folder (/)
instead, which is not visible from the IDE.
To work around this issue, reject the suggested destination and use /projects
.
3.15. 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.
3.16. Inability to install CodeReady Workspaces on OpenShift Container Platform 3.11 without cluster-admin role
The customer in an organization with a strict security policy cannot install CodeReady Workspaces v2.1.1 on OCP 3.11 cluster with the crwctl
utility, which requires a user with cluster-admin privileges.
3.17. Proxy settings blocks access to dependencies of building tools in restricted environments
For instances of CodeReady Workspaces deployed in restricted environments, their proxy blocks to reach downloadable dependencies for building tools such as Maven, Gradle, and others.
To work around this issue, configure the proxy settings to allow the specific builder to reach needed dependencies.
3.18. Partially-deployed CRW Operator crashes if the CheCluster custom resource is deleted
A partially-deployed codeready-operator, installed from the OperatorHub, crashes after deleting a CheCluster CR.
(runtime error: invalid memory address or nil pointer dereference)
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.
Chapter 4. Known Issues for CodeReady Workspaces on IBM Z and IBM Power Systems
4.1. IBM Z [Technology Preview]
Support for deploying CodeReady Workspaces on OpenShift Container Platform on IBM Z is currently only available as a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For details about the level of support for Technology Preview features, see Technology Preview Features Support Scope.
4.1.1. Unsupported devfiles on IBM Z
- EAP for OpenJDK 8
- .Net
- Fuse
4.1.2. Debugging cannot be activated in Go workspaces
Delve
is a debugger for the Go programming language which is not available for IBM Z architecture, therefore debugging features cannot be activated in Go workspace in CodeReady Workspaces 2.8. An attempt to activate this feature results in the Failed to continue
error message.
4.2. IBM Power Systems [Technology Preview]
Support for deploying CodeReady Workspaces on OpenShift Container Platform on IBM Power Systems is currently only available as a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For details about the level of support for Technology Preview features, see Technology Preview Features Support Scope.
4.2.1. Unsupported devfiles on IBM Power Systems
- EAP for OpenJDK 8
- .Net
- Fuse
4.2.2. Debugging cannot be activated in Go workspaces
Delve
is a debugger for the Go programming language which is not available for IBM Power Systems architecture, therefore debugging features cannot be activated in Go workspace in CodeReady Workspaces 2.8. An attempt to activate this feature results in the Failed to continue
error message.
4.2.3. Increase in RAM requirements to allow pods to run
For IBM Power Systems (ppc64le), the memory limit for some plug-ins has been increased by up to 1.5G to allow pods sufficient RAM to run. For example, on IBM Power Systems (ppc64le), the Che-Theia editor pod requires 2G; the OpenShift connector pod requires 2.5G. For AMD64 and Intel 64 (x86_64) and IBM Z (s390x), memory requirements remain lower at 512M and 1500M respectively.
However, some devfiles may still be configured to set the lower limit valid for AMD64 and Intel 64 (x86_64) and IBM Z (s390x), so to work around this, edit devfiles for workspaces that are crashing to increase the default memoryLimit by at least 1 - 1.5 GB.
4.2.4. Missing debug configurations in devfiles on IBM Power Systems
Missing debug configurations for CakePHP, PHPDI, Nodejs, Quarkus, and Spring Boot devfiles on OpenShift Container Platform 4.7 and 4.6.
These debug configurations appear automatically in .theia
folder after 5-10 minutes after a workspace start.
Chapter 5. 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 Container Platform 3.11 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