Chapter 3. Known issues

This section lists known issues with Red Hat CodeReady Workspaces 2.4. Where available, workaround suggestions are provided.

3.1. CodeReady Workspaces 2.3 Go workspaces fail to migrate to 2.4

The Go language plug-in moved from the v3/plugins/ms-vscode/ directory to v3/plugins/golang directory in the plug-in registry. As a result, the older workspaces created from the Go devfile cannot migrate to the current release version.

To resolve this issue:

  1. In the Go devfile components, replace the ms-vscode/go/latest ID with golang/go/latest: 

    components:
 - id: golang/go/latest

3.2. ubi8-minimall image is not automatically mirrored for an disconnected environment installation

Following the steps in Using Operator Lifecycle Manager on restricted networks chapter in OpenShift docummentation, leads to an issue when ubi8-minimal image is not present in the mappings.txt and imageContentSourcePolicy.yaml files, causing an installation in a disconnected environment to fail.

To work around this issue:

  1. Mirror the image manually: 

    $ skopeo copy --all docker://registry.stage.redhat.io/ubi8-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187aadb32e89fd83fa455ebaa6 docker://${INTERNAL_REGISTRY}/ubi8-minimal

  2. Add a new rule for ubi8-minimal to imageContentSourcePolicy, or edit the imageContentSourcePolicy directly on a cluster, if already created: 

    - mirrors:
  - ${INTERNAL_REGISTRY}/ubi8-minimal
  source: registry.stage.redhat.io/ubi8-minimal

3.3. Debug session for Python devfile fails to start

CodeReady Workspaces2.4 instances does not support a debug session for workspaces created from a Python devfile.

3.4. The Apache Camel K stack, provided in "Get started", is not supported for CodeReady Workspaces 2.4

All Camel K specific commands and Camel K Integration explorer are not working out of the box.

To work around this issue:

  • in Preferences → Camelk → Integrations, disable the auto-upgrade option and specify Camel K Runtime executable to match version 1.0.0.

    or

  • Add the VS Code extension 0.0.16 tooling for Apache Camel K in the registry.
  • CRW-1197

3.5. CodeReady Workspaces requires wildcard SSL certificates

CodeReady Workspaces requires a new sub-domain for every workspace it manages. This can lead to an inefficient situation when CodeReady Workspaces manages a large number of workspaces, while managing a conventional certificate for each of these workspaces. Administrators can try to work around this by setting a wildcard TLS certificate to secure all OpenShift routes of dedicated workspaces.

In case it is not possible to enable wildcard certificates globally on the OpenShift router, use a dedicated router for CodeReady Workspaces workspaces and Ingress Controller sharding. See Configuring Ingress Controller sharding by using route labels

  1. Add a dedicated ingress controller to serves the CodeReady Workspaces workspace routes using route label filtering and configured with a wildcard-based certificate signed by the corporate CA chain.
  2. Specify the route filtering of the dedicated ingress controller: 
routeSelector:
   matchExpressions:
      key: che.workspace_id
      operator: Exists

3.6. 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.7. Installing CodeReady Workspaces using crwctl server:start fails in clusters with multiple CodeReady Workspaces deployments

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.

3.8. 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 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

3.9. PHP language server marks valid imports as erroneous in PHP-DI devfile

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

To work around this issue:

  1. Install the PHP dependencies using the Install dependencies IDE command.
  2. If not done automatically after the dependencies installation, restart the workspace manually.

  3. Refresh the browser.

3.10. The workspace sharing does not work

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

3.11. The crwctl server:delete command breaks existing CodeReady Workspaces deployments on the same OpenShift cluster

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.

3.12. 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.13. Creating a namespace fails when a login name with unsupported characters is used

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:

  • Use the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT property with <userid> or <workspaceid> instead of <username> .

  • Use the CHE_INFRA_KUBERNETES_NAMESPACE_ALLOW_USER_DEFINED property to allow users to select namespaces by themselves.

3.14. Using of NFS mounts may cause installation or workspace start failures

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

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.