Chapter 2. Known issues

When a user wants to test an application created in the Java Spring Boot devfile workspace by deploying it to OpenShift, an error message during the application deployment interrupts the process:

Execution fmp of goal io.fabric8:fabric8-maven-plugin:3.5.40:build failed: No <dockerHost> given, no DOCKER_HOST environment variable, no read/writable '/var/run/docker.sock' or '//./pipe/docker_engine' and no external provider like Docker machine configured

To work around this issue, refresh the page of the browser using F5 or Ctrl-r on macOS.

Applies for situations when an administrator wants to restrict users' privileges to create namespaces and pre-create them before the CodeReady Workspaces installation.

To work around this issue, use the OpenShift username when logging into CodeReady Workspaces.

On OpenShift 4.4, the catalog bundle image is corrupted and does not appear in OperatorHub. To workaround this issue, update to OpenShift 4.5.

Installation of CodeReady Workspaces, using the crwctl server:start with OpenShift OAuth, fails or does not deploy resources if existing resources from another crwctl installation exist in the cluster.

To workaround this issue, delete old resources and perform a fresh installation. For instructions, see step 6 of the Installing CodeReady Workspaces on OpenShift 3 using the Operator Installation Guide chapter.

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.

When CodeReady Workspaces deployed on OpenShift encounters a certificate error, the error notification links to the wrong remediation instructions.

To import the certificates, see: Installing Codeready Workspaces in TLS mode with self-signed certificates

Some of the sample projects included in the Getting Started devfiles 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

Workspaces created from the PHP-DI devfile incorrectly highlight valid code as erroroneous.

To work around this issue:

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

$ crwctl workspace:inject -k -n workspaces-server
› Current Kubernetes context: 'workspaces-server/api-che-devex-devcluster-openshift-com:6443/system:admin'
 ›   Error: Authentication is enabled but 'access-token' is not provided.
 ›   See more details with the --help flag.

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

Other failing commands:

The File > Share IDE command currently launches the Workspace tab, but the Share tab is missing.

The crwctl server:delete command removes certain cluster-scoped objects, which causes all other CodeReady Workspaces deployments to terminate unexpectedly.

To work around the issue, patch the Custom Resource Definition:

+

$ oc patch customresourcedefinition/checlusters.org.eclipse.che -p \
'{ "metadata": { "finalizers": null }}' --type merge

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.

Instead of removing checluster from the current CodeReady Workspaces project, the checluster is deleted from all projects in the OpenShift Container Platform cluster.

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.

By default, the OpenShift Connector plug-in logs in to the cluster as inClusterUser, which in some cases does not have the manage project permission. This causes an error message to be displayed when creating a new project 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.

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

If the <username>-che namespace strategy is used, a problem can occur with the user names that contain characters incompatible with the Kubernetes namespace name pattern.

The specified namespace example@redhat.com-codeready is invalid: a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name', or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')

To work around this issue, do one of the following:

For best performance, Red Hat recommends using block storage for Persistent Volumes used with CodeReady Workspaces. The use of NFS is not recommended.

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.

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