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:

  1. Open a devfile of the affected workspace using Dashboard and the Devfile tab.
  2. Replace the id of the components 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.