Release Notes and Known Issues
Release Notes and Known Issues for Red Hat CodeReady Workspaces 2.6
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.6 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.
1.1. About Red Hat CodeReady Workspaces
Red Hat CodeReady Workspaces 2.6 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.24 and offers a number of enhancements and new features, including:
- Improvements to workspace start and overall performance
Bug fixes, such as:
- Missing Kerberos authentication for Operator deployments
- Missing Health endpoint for CodeReady Workspaces Operator
- Missing list of plug-ins in 'Plugins' tab of the CRW 2.5 IDE
- Error of deploying to the quay.io CodeReady Workspaces devfile registries (rhel8:2.6-20 / 2.6-26) on OCP 3.11 and 4.6
- Che-Theia Web View doesn’t work properly when a plug-in runs in its sidecar
Plugin and Devfile Registry Updates
Language updates
- Support for JBoss EAP Extension Pack 2.0
- Python updated to 3.8, support added for the Pylint code analyzing tool, and all the known CVEs related to Python were resolved.
Plug-in updates
- VS Code Camel K plug-in updated from 0.0.18 to 0.0.19
- Language Support for Apache Camel extension updated from 0.0.28 to 0.0.30
- VS Code XML plug-in updated from 0.11.0 to 0.14.0
- VS Code Python plug-in updated from 2019.5.18875 to 2020.7.94776
- OpenShift connector plug-in downgraded to 0.1.5. See CRW-1429
CodeReady Workspaces 2.6 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.6 is available from the OperatorHub in OpenShift 4.6 and beyond. CodeReady Workspaces 2.6 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. Support for the CodeReady Workspaces crwctl
installation method
The use of crwctl
is now fully supported for all OCP 4.6 instances and acts as another installation option for CodeReady Workspaces. The crwctl
provides a command-line tool alternative to the Operator Lifecycle Manager (OLM) UI.
Basic commands:
-
crwctl server:deploy
-
crwctl server:delete
1.2.2. Initial support of the factory flow with Bitbucket
Supporting the factory flow with Bitbucket provides the use of private and public Git repositories hosted on a Bitbucket server by manually adding personal access tokens to users' projects. The use of these tokens is to sign Bitbucket REST API calls and perform operations in Git repositories.
1.2.3. Usage of cluster internal service hostname for inter-component communication
By default, new CodeReady Workspaces deployments use a cluster internal service hostname for communication between CodeReady Workspaces server, Red Hat Single Sign-On, and registry components.
This improvement helps with bypassing proxy, certificates, and firewalls issues.
To enable this feature in the updated CodeReady Workspaces instance installed in the previous version, edit the Custom Resource (CR):
$ oc patch checluster codeready-workspaces -n openshift-workspaces --type=json -p \ '[{"op": "replace", "path": "/spec/server/useInternalClusterSVCNames", "value": true}]'
OpenShift restrictions:
- This feature does not support multi-cluster OpenShift environments.
- The OpenShift environment restricts communication between namespaces.
1.2.4. Ability to mount Secrets into CodeReady Workspaces containers using annotations
An administrator can now annotate custom Secrets deployment to mount them into the CodeReady Workspaces Pods. Mounting a specific secret into Red Hat Single Sign-On containers helps to configure user authentication with Kerberos credentials.
1.2.5. Added support for JBoss EAP Extension Pack 2.0 Bootable JAR
This extension provides CodeReady Workspaces with a possibility to package your application as a bootable JAR or as a hollow bootable JAR in JBoss EAP XP 2.0.0. using the recently added devfile. A bootable JAR contains a server, a packaged application, and the runtime required to launch the server.
- A second devfile for the new Bootable JAR feature was added in EAP XP 2. This devfile is available for all CodeReady Workspaces architectures. See CRW-1419
- The existing XP devfiles on IBM Z and IBM Power Systems architectures still use XP1.
For details, see the JBoss EAP Extension Pack 2.0 Release Notes document.
1.2.6. Added support for EsLint
The vscode-eslint
extension is now installable from the plug-in registry. It acts as a support for a use of JavaScript in the IDE, where it helps as a statically analyzing and automatic fixing tool.
1.2.7. VS Code GitHub Pull Request plug-in added to Plugin Registry
VS Code GitHub Pull Request plug-in is now included in CodeReady Workspaces and provides the ability to:
- Authenticate and connect CodeReady Workspaces to GitHub.
- Review and manage pull requests.
- List and browse PRs from within CodeReady Workspaces.
- Interact with PRs in-editor, including in-editor commenting with Markdown support.
- Use the terminal integration in which CodeReady Workspaces UI and command-line tools, such as Git, can co-exist.
1.3. Other enhancements
1.3.1. Support for fractional values of cores needed to run devfiles
Users can now specify fractional values for CPU Request and Limit fields when configuring devfiles.
-
Valid values:
11
,1
,1.1
,0.1
,0.01
,1m
,100m
,1000m
-
Invalid values:
1.1.1
,1.1m
,0m
,1k
1.4. Support terminations and deprecations
The following elements have been replaced or removed from CodeReady Workspaces 2.6.
-
The
crwctl server:start
command has been replaced withcrwctl server:deploy
. - The Red Hat Fuse devfile has been removed for CodeReady Workspaces running on IBM Z & P as Red Hat Fuse is not supported on those architectures.
-
The
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.6, 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.6 on OpenShift Container Platform 4.6, 3.11, and OpenShift Dedicated.
Table 2.1. Supported deployment environments for CodeReady Workspaces 2.6 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 Dedicated 4.6 | AMD64 and Intel 64 (x86_64) | Add-On |
Support for deploying CodeReady Workspaces on OpenShift Container Platform on IBM Power Systems (ppc64le) and IBM Z (s390x) 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.6, Red Hat will provide support for deployment, configuration, and use of the product.
CodeReady Workspaces 2.6 has been tested on Chrome version 87.0.4280.141 (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.6. Where available, workaround suggestions are provided.
3.1. CodeReady Workspaces cannot be installed with default settings in the proxied environment using OperatorHub on OpenShift Container Platform 4.6
During a installation on OpenShift Container Platform 4.6 using OperatorHub the CodeReady Workspaces Pod fails to deploy with following error message:
Error in custom provider, java.lang.RuntimeException: Exception while retrieving OpenId configuration from endpoint: http://keycloak.crw-ohub-with-proxy.svc:8080/auth/realms/codeready/.well-known/openid-configuration
To work around this issue, add the .svc
value to nonProxyHosts
property of CheCluster Custom Resource. See Preparing CodeReady Workspaces Custom Resource for installing behind a proxy.
3.2. Temporary factory authentication flow for Bitbucket with required manual configuration
CodeReady Workspaces provides the ability to use factories with Bitbucket repositories. The current factory authentication flow requires manual configuration for the user’s project credentials that the user or administrator must do.
For more information, see Configuring Bitbucket servers and Deploying CodeReady Workspaces with support for Git repositories with self-signed certificates.
3.3. Upgrade to CodeReady Workspaces version 2.6 using crwctl
fails on OpenShift Container Platform 3.11
The crwctl server:update
command fails if executed from a folder where another templates directory exists.
Ensure there is no templates
subdirectory, with a not-relate content to crwctl, in the directory from which the crwctl server:update
command is executed.
3.4. Signing in to GitHub from a CodeReady Workspaces workspace using the GitHub plug-in fails
When this issue occurs, connect a GitHub account using the CodeReady Workspaces user dashboard to sign into the GitHub repository.
Make sure that GitHub OAuth is set. Then follow one of the described possibilities about how to add a GitHub account to CodeReady Workspaces.
From the Workspace tab of the main dashboard screen:
- Navigate to the Project sub-tab.
- Click the Add Project button.
- From the GitHub tab, use the Add your GitHub account button.
From the left bottom menu of the main dashboard screen:
- Click Account and continue with the Edit button, which will forward you to the Red Hat Single Sign-On main screen.
- From the left menu, select the Federated identity tab.
- Add the GitHub account using the Add button.
- CRW-1563
3.5. 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.6. Some workspace plug-ins do not load behind a proxy
To work around this issue:
Set the
useInternalClusterSVCNames
value tofalse
using the Custom Resource YAML file.
3.7. Workspaces on OpenShift Container Platform 4.6 fail to start when cluster-wide proxy settings are applied
Workspaces with useInternalClusterSVCNames
environment variable set to true
fail on OpenShift Container Platform 4.6 clusters with wide proxy settings applied.
To work around this issue:
Set the
useInternalClusterSVCNames
environment variable tofalse
using the Custom Resource YAML file.
3.8. Logging in to a CodeReady Workspaces workspace using the crwctl
tool fails with OpenShift OAuth support enabled.
The crwctl auth:login
utility fails to log in to CodeReady Workspaces with OAuth support.
To work around this issue:
Set the
useInternalClusterSVCNames
environment variable tofalse
using the Custom Resource YAML file.
3.9. Breakpoints of the debug session do not work correctly in a Quarkus workspace
A breakpoint is currently triggered only if it is set during the current debug session.
3.10. 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.11. 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.12. 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.13. The Topology view does not respect CodeReady Workspaces icon on OpenShift Container Platform 4.6
After creating an application in the Developer console of OpenShift Container Platform 4.6, the Edit source icon in the Topology view displays as Eclipse Che logo.
3.14. The Install dependencies
command fails in the PHP-DI workspace on OpenShift Container Platform 4.6
The Install dependencies (with composer)
command, predefined the php-di/console.php
file, fails in a workspace created using the PHP-DI default yaml.
3.15. 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.16. 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.17. 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.18. 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.19. 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)
3.20. 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.21. CodeReady Workspaces 2.5 Red Hat Fuse workspaces fail to start after migration to 2.6
CodeReady Workspaces 2.5 Red Hat Fuse workspaces deployed on OpenShift with enabled OpenShift OAuth support fail to start after updating to 2.6.
3.22. Manually added registries using Theia Plugin View are not reflected in the View automatically
To work around this issue, refresh the page by pressing F5 or Comd+r if using macOS.
3.23. 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 section 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
3.24. 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.
3.25. 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.
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. Installations in restricted environments are not supported on IBM Z
Advanced features like, for example, restricted environment installation, while possible, are unsupported.
4.1.2. Unsupported devfiles on IBM Z
- EAP for OpenJDK 8
- .Net
- Fuse
4.1.3. Debugging cannot be activated in Go workspaces
Debugging feature cannot be activated in Go workspace in CodeReady Workspaces 2.6. 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
Debugging feature cannot be activated in Go workspace in CodeReady Workspaces 2.6. An attempt to activate this feature results in the Failed to continue
error message.
4.2.3. Che-Theia is going in CrashLoopBackOff
state when creating a workspace on IBM Power Systems
To work around this issue:
Refresh the browser.
or
Add more memory for the plug-ins:
- Go to the CodeReady Workspaces installation namespace.
-
Get inside the
plugin-registry
Pod. Modify the
memoryLimit
value to 2Gi inside the plugin-registry pod:$ oc rsh <plugin-registry-pod-name>
$ vi v3/plugins/eclipse/che-theia/next/meta.yaml
- CRW-1475
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