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.

  • Bitbucket support lacks the following features:

    • 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-1372
  • CRW-1490

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:

    1. Navigate to the Project sub-tab.
    2. Click the Add Project button.
    3. From the GitHub tab, use the Add your GitHub account button.
  • From the left bottom menu of the main dashboard screen:

    1. Click Account and continue with the Edit button, which will forward you to the Red Hat Single Sign-On main screen.
    2. From the left menu, select the Federated identity tab.
    3. 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:

  1. Set the useInternalClusterSVCNames value to false 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:

  1. Set the useInternalClusterSVCNames environment variable to false 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:

  1. Set the useInternalClusterSVCNames environment variable to false 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.