Chapter 9. Troubleshooting Dev Spaces This section provides troubleshooting procedures for the most frequent issues a user can come in conflict with. Additional resources Section 9.1, "Viewing Dev Spaces workspaces logs" Section 9.2, "Troubleshooting slow workspaces" Section 9.3, "Troubleshooting network problems" Section 9.4, "Troubleshooting webview loading error" 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 OOMKilled error 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 Section 9.1.1, "Workspace logs in CLI" Section 9.1.2, "Workspace logs in OpenShift console" Section 9.1.3, "Language servers and debug adapters logs in the editor" 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: 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 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.server or similar configuration to verbose , 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 Open VSX registry 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.19/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.19/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 1 Specifies the CPU limit 2 Specifies the CPU request 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.yaml file are correct. components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest memoryLimit: 6G 1 memoryRequest: 512Mi 2 1 Specifies the memory limit 2 Specifies the memory request 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 Table 9.1. Dealing with the webview error in a private browsing window Browser Workarounds Google Chrome Go to Settings Privacy and security Cookies and other site data Allow all cookies . Mozilla Firefox Webviews are not supported in Private Browsing mode. See this reported bug for details.

Commands:
oc logs --follow --namespace=' <workspace_namespace> ' --selector='controller.devfile.io/devworkspace_name= <workspace_name> '
components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest cpuLimit: 4000m 1 cpuRequest: 1000m 2
components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest memoryLimit: 6G 1 memoryRequest: 512Mi 2