Chapter 2. Known issues

Users with the cluster-admin role who use OpenShift 3.11 may experience the 2.0 version java-eap-maved-based workspaces with TLS and OpenShift OAuth support fail to start after the product server is updated to version 2.1.1. Users are then not permitted to access the old Persistent Volume.

To work around this issue, create a new 2.1.1 workspace using the same devfile that was used to create the workspace in the previous version.

By default, the Openshift Connector plug-in logs into the cluster as inClusterUser, which may not have the manage project permission. This causes an error message to be displayed when a new project is being created 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.

Absence of the debug configuration, situated in the debug panel of a created workspace, when the Node JS Config Map devfile is used for a new workspace creation.

The dedicated crwctl command crwctl server:stop 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.

The crwctl workspace:inject command causes the error during the workspace Pod localization in workspaces created with OpenShift OAuth support.

$ crwctl workspace:inject -n codeready-tls-oauth -k
  ✔ Verify if namespace codeready-tls-oauth exists
  ✖ Verify if the workspaces is running
     No workspace pod is found
    Injecting configurations
 ›   Error: No workspace pod is found

To work around the issue, use oc login command inside the affected container instead.

When a workspace has been created in a dedicated namespace that is later entirely deleted, the corresponding OpenShift project needs to be removed manually to complete the deletion process.

To work around the issue: delete the remaining empty project from the OpenShift console:

$ oc delete project <projectname>

After using the crwctl server:delete command, the OpenShift project that used to host the CodeReady Workspaces instance remains. This makes it impossible to install a new CodeReady Workspaces instance into the default namespace, which still exists. To uninstall CodeReady Workspaces completely, manually remove the namespace.

To work around the issue:

Creation of the CodeReady Workspaces cluster, codeready-workspaces, in a namespace can be affected by previous use of the crwctl server:delete uninstallation command.

To work around the issue:

An embedded application of the Java EAP Maven stack in the debug mode tends to fail. The dialog window with application URL is already displayed, but the application, according to the terminal output, is still starting. The use of the URL link displayed leads to an error.

Attempting to restart a workspace and re-enter it fails, and an error message is displayed instead. To work around this issue, restart the workspace again.

The Workspace Cap and Workspace RAM cap functions, which control the maximum number of workspaces for an organization and the maximum RAM that organization workspaces can use, currently do not work.

Devfiles contain a set of predefined commands that can be executed in workspaces started using devfiles from the devfile registry. However, when a command defined by a devfile is executed from the workspace, the terminal, in which the commands normally run, does not open.

The work around this issue, do not open the same workspace link in two different browsers.

Due to CodeReady Workspaces and OpenShift OAuth integration, workspaces are not stopped by the idling timeout, when the workspace is located in a user’s Pod.

To work around this issue, disable the stopping of idling workspace by timeout feature for the workspaces with OpenShift OAuth integration:

$ oc patch checluster/eclipse-che --patch "{\"spec\":{\"server\":{\"customCheProperties\": {\"CHE_LIMITS_WORKSPACE_IDLE_TIMEOUT\": \"-1\"}}}}" --type=merge -n che

To workaround this issue, update the Go language server plug-in to the latest version.

In workspaces based on the Go devfile, an error notification is displayed during the start of the Debug current file configuration.

To work around this issue, execute the predefined Run current file command first, then repeat the debugging procedure.