-
Language:
English
-
Language:
English
Chapter 2. Known issues
This section lists known issues with Red Hat CodeReady Workspaces 2.2. Where available, workaround suggestions are provided.
2.1. OpenShift Container Platform Developer Topology Perspective view is not working as expected
The Edit source code
icon does not work properly from Developer Topology Perspective.
After the an CodeReady Workspaces application deploys, the topology view should display a clickable icon that loads a CodeReady Workspaces workspace using the devfile that is in the source repository. Instead, it displays the GitHub icon that brings the user to the GitHub source code repository.
2.2. Cannot install CRW on a cluster configured with an authenticated proxy
When installing CRW on a cluster configured with an authenticated proxy, the installation fails because the CodeReady Workspaces server cannot contact the RH-SSO OIDC endpoint.
2.3. AirGap installation of CodeReady Workspaces 2.2 does not work on OpenShift 4.4
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.
2.4. Installing via crwctl in operator mode in some cases fails
Installation of CodeReady Workspaces with OpenShift OAuth using crwctl in operator
mode in some cases fails or does not deploy resources if existing resources from another crwctl 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.
2.5. Dashboard splash screen refers to an incorrect location on OpenShift 3.11
When CodeReady Workspaces deployed on OpenShift 3.11 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
2.6. The Getting started
examples are failing in the AirGap mode 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
2.7. The Terminate Task
IDE function does not work properly on OpenShift 4.4 and AWS
Tasks terminated with the Terminate Task
IDE function do not end properly. As a consequence, reactivating the task returns an `The task is already running active` error with the option to use the Restart task
function. However, using this function causes a port conflict and the task fails.
2.8. The Go to definition
and Debug
functions do not work in the Go
workspace
Some devfiles are provided as Technology Preview and are not guaranteed to work for all implementations.
2.9. Syntax highlighting 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:
-
Install the PHP dependencies using the
Install dependencies
IDE command. - If not done automatically after the dependencies installation, restart the workspace manually.
Refresh the browser.
2.10. The crwctl workspace:inject
command does not work in workspaces with OpenShift OAuth support
The crwctl workspace:inject
command causes the following 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 the oc login
command inside the affected container instead.
2.11. OpenShift Projects remain present after a namespace deletion in CodeReady Workspaces 2.2
When a workspace is created in a dedicated namespace and the namespace is later entirely deleted, the corresponding OpenShift project currently does not get deleted.
To complete the deletion process, delete the project manually from the OpenShift console:
$ oc delete project <projectname>
2.12. The crwctl server:delete
command does not remove the OpenShift project
After using the crwctl server:delete
command, the OpenShift project hosted the CodeReady Workspaces instance remains. This makes it impossible to install a new CodeReady Workspaces instance into the still existing default namespace.
To uninstall CodeReady Workspaces completely, remove the namespace manually:
Stop the Red Hat CodeReady Workspaces Server:
$ crwctl server:stop
Obtain the name of the CodeReady Workspaces namespace:
$ oc get checluster --all-namespaces -o=jsonpath="{.items[*].metadata.namespace}"
Remove CodeReady Workspaces from the cluster:
$ crwctl server:delete -n <namespace>
This removes all CodeReady Workspaces installations from the cluster.
Delete the
checluster
object and thecodeready-workspaces
resource:$ oc delete checluster codeready-workspaces --namespace=<openshift_namespace>
<openshift_namespace>
is the name of the OpenShift project where CodeReady Workspaces is deployed.Delete the OpenShift namespace:
$ oc delete project <openshift_namespace>
2.13. The workspace sharing does not work
The File > Share
IDE command currently launches the Workspace
tab, but the Share
tab is missing.
2.14. The crwctl workspace:delete
command cannot find already started workspace
To work around the issue:
-
Use
crwctl server:stop
Use
crwctl workspace:delete
again
2.15. 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.
2.16. The crwctl server:delete
command incorrectly removes checluster
from all CodeReady Workspaces projects on OpenShift Container Platform
Instead of removing checluster
from the current CodeReady Workspaces project, the checluster
is deleted from all projects in the OpenShift Container Platform cluster.
2.17. 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.
2.18. OpenShift Connector plug-in requires manually connecting to the target cluster
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.
2.19. An embedded application of the java-eap-maven
stack tends to fail to launch in the debug mode
When launching an embedded application of the java-eap-maven
stack in the debug mode, the launch often fails. The dialog window with the application URL is already displayed, but the terminal output states that the application is still starting. Using the URL link displayed causes an error.
2.20. Error highlighting and code completion do not work in a Go devfile
To work around this issue, update the Go language server plug-in to the latest version.
2.21. Mounting a Kubernetes secret into a workspace container does not work on OpenShift 3.11
The subPath
in VolumeMount
property, necessary for mounting secrets, is supported on Kubernetes version 1.15, where OpenShift 3.11 is based on Kubernetes version 1.11. As a consequence, mounting a Kubernetes secret into a workspace container does not work.
2.22. 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.
2.23. Using of NFS mounts may cause installation or workspace startup failures
For best performance, Red Hat recommends using block storage for Persistent Volumes used with CodeReady Workspaces. The use of NFS is not recommended.
2.24. 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.
2.25. CodeReady Workspaces fails to shut down after executing crwctl server:stop
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.