Questo contenuto non è disponibile nella lingua selezionata.
Chapter 9. Troubleshooting Dev Spaces
This section provides troubleshooting procedures for the most frequent issues a user can come in conflict with.
Additional resources
9.1. Viewing Dev Spaces workspaces logs
You can view OpenShift Dev Spaces logs to better understand and debug background processes should a problem occur.
- An IDE extension misbehaves or needs debugging
- The logs list the plugins that have been loaded by the editor.
- The container runs out of memory
-
The logs contain an
OOMKillederror message. Processes running in the container attempted to request more memory than is configured to be available to the container. - A process runs out of memory
-
The logs contain an error message such as
OutOfMemoryException. A process inside the container ran out of memory without the container noticing.
Additional resources
9.1.1. Workspace logs in CLI
You can use the OpenShift CLI to observe the OpenShift Dev Spaces workspace logs.
Prerequisites
- The OpenShift Dev Spaces workspace <workspace_name> is running.
- Your OpenShift CLI session has access to the OpenShift project <namespace_name> containing this workspace.
Procedure
Get the logs from the pod running the <workspace_name> workspace in the <namespace_name> project:
$ oc logs --follow --namespace='<workspace_namespace>' \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>'
9.1.2. Workspace logs in OpenShift console
You can use the OpenShift console to observe the OpenShift Dev Spaces workspace logs.
Procedure
- In the OpenShift Dev Spaces dashboard, go to Workspaces.
- Click on a workspace name to display the workspace overview page. This page displays the OpenShift project name <project_name>.
- Click on the upper right Applications menu, and click the OpenShift console link.
- Run the next steps in the OpenShift console, in the Administrator perspective.
- Click Workloads > Pods to see a list of all the active workspaces.
- In the Project drop-down menu, select the <project_name> project to narrow the search.
- Click on the name of the running pod that runs the workspace. The Details tab contains the list of all containers with additional information.
- Go to the Logs tab.
9.1.3. Language servers and debug adapters logs in the editor
In the Microsoft Visual Studio Code - Open Source editor running in your workspace, you can configure the installed language server and debug adapter extensions to view their logs.
Procedure
-
Configure the extension: click File > Preferences > Settings, expand the Extensions section, search for your extension, and set the
trace.serveror similar configuration toverbose, if such configuration exists. Refer to the extension documentation for further configuration. -
View your language server logs by clicking View
Output, and selecting your language server in the drop-down list for the Output view.
Additional resources
9.2. Troubleshooting slow workspaces
Sometimes, workspaces can take a long time to start. Tuning can reduce this start time. Depending on the options, administrators or users can do the tuning.
This section includes several tuning options for starting workspaces faster or improving workspace runtime performance.
9.2.1. Improving workspace start time
- Caching images with Image Puller
Role: Administrator
When starting a workspace, OpenShift pulls the images from the registry. A workspace can include many containers meaning that OpenShift pulls Pod’s images (one per container). Depending on the size of the image and the bandwidth, it can take a long time.
Image Puller is a tool that can cache images on each of OpenShift nodes. As such, pre-pulling images can improve start times. See https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.17/html-single/administration_guide/index#administration-guide:caching-images-for-faster-workspace-start.
- Choosing better storage type
Role: Administrator and user
Every workspace has a shared volume attached. This volume stores the project files, so that when restarting a workspace, changes are still available. Depending on the storage, attach time can take up to a few minutes, and I/O can be slow.
- Installing offline
Role: Administrator
Components of OpenShift Dev Spaces are OCI images. Set up Red Hat OpenShift Dev Spaces in offline mode to reduce any extra download at runtime because everything needs to be available from the beginning. See https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.17/html-single/administration_guide/index#administration-guide:installing-che-in-a-restricted-environment.
- Reducing the number of public endpoints
Role: Administrator
For each endpoint, OpenShift is creating OpenShift Route objects. Depending on the underlying configuration, this creation can be slow.
To avoid this problem, reduce the exposure. For example, to automatically detect a new port listening inside containers and redirect traffic for the processes using a local IP address (
127.0.0.1), Microsoft Visual Code - Open Source has three optional routes.By reducing the number of endpoints and checking endpoints of all plugins, workspace start can be faster.
9.2.2. Improving workspace runtime performance
- Providing enough CPU resources
Plugins consume CPU resources. For example, when a plugin provides IntelliSense features, adding more CPU resources can improve performance.
Ensure the CPU settings in the devfile definition,
devfile.yaml, are correct:components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest cpuLimit: 4000m 1 cpuRequest: 1000m 2- Providing enough memory
Plug-ins consume CPU and memory resources. For example, when a plugin provides IntelliSense features, collecting data can consume all the memory allocated to the container.
Providing more memory to the container can increase performance. Ensure that memory settings in the devfile definition
devfile.yamlfile are correct.components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest memoryLimit: 6G 1 memoryRequest: 512Mi 2
9.3. Troubleshooting network problems
This section describes how to prevent or resolve issues related to network policies. OpenShift Dev Spaces requires the availability of the WebSocket Secure (WSS) connections. Secure WebSocket connections improve confidentiality and also reliability because they reduce the risk of interference by bad proxies.
Prerequisites
- The WebSocket Secure (WSS) connections on port 443 must be available on the network. Firewall and proxy may need additional configuration.
Procedure
- Verify the browser supports the WebSocket protocol. See: Searching a websocket test.
- Verify firewalls settings: WebSocket Secure (WSS) connections on port 443 must be available.
- Verify proxy servers settings: The proxy transmits and intercepts WebSocket Secure (WSS) connections on port 443.
9.4. Troubleshooting webview loading error
If you use Microsoft Visual Studio Code - Open Source in a private browsing window, you might encounter the following error message: Error loading webview: Error: Could not register service workers.
This is a known issue affecting following browsers:
- Google Chrome in Incognito mode
- Mozilla Firefox in Private Browsing mode
| Browser |
|---|
| Workarounds |
| Google Chrome |
|
Go to Settings |
| Mozilla Firefox |
| Webviews are not supported in Private Browsing mode. See this reported bug for details. |
