Camel devfiles are not able to start because of OOMKilled

Describe the bug

The workspace is not started with the OOMKilled message shown. Same for Apache Camel K and Apache Camel based on Spring Boot devfiles.

Che version

• latest
• nightly
• other: please specify 7.25.0

Steps to reproduce

1. Go to Dashboard, click Get Started menu item, open Get Started tab.
2. Select Apache Camel K project or Apache Camel based on Spring Boot devfile.
3. Wait for the error to appear.

Expected behavior

Example devfiles should work out-of-the-box.

Runtime

• kubernetes (include output of kubectl version)
• Openshift (include output of oc version) 4.7
• minikube (include output of minikube version and kubectl version)
• minishift (include output of minishift version and oc version)
• docker-desktop + K8S (include output of docker version and kubectl version)
• other: (please specify) Hosted Che

Screenshots

Installation method

• chectl
  • provide a full command that was used to deploy Eclipse Che (including the output)
  • provide an output of chectl version command
• OperatorHub
• I don’t know

Environment

• my computer
  • Windows
  • Linux
  • macOS
• Cloud
  • Amazon
  • Azure
  • GCE
  • other (please specify)
• other: please specify - Linux OpenStack

Eclipse Che Logs

Error part:

2021-02-01 14:12:03,334[aceSharedPool-1]  [WARN ] [.i.k.KubernetesInternalRuntime 257]  - Failed to start Kubernetes runtime of workspace workspaceftoo1v6yq5wxqg7t.
org.eclipse.che.api.workspace.server.spi.InfrastructureException: The following containers have terminated:
vscode-apache-camelccf: reason = 'OOMKilled', exit code = 137, message = 'null'
	at org.eclipse.che.workspace.infrastructure.kubernetes.namespace.KubernetesDeployments.handleStartingPodStatus(KubernetesDeployments.java:465)
	at org.eclipse.che.workspace.infrastructure.kubernetes.namespace.KubernetesDeployments$2.eventReceived(KubernetesDeployments.java:378)
	at org.eclipse.che.workspace.infrastructure.kubernetes.namespace.KubernetesDeployments$2.eventReceived(KubernetesDeployments.java:375)
	at io.fabric8.kubernetes.client.utils.WatcherToggle.eventReceived(WatcherToggle.java:49)
	at io.fabric8.kubernetes.client.dsl.internal.WatchConnectionManager$1.onMessage(WatchConnectionManager.java:237)
	at okhttp3.internal.ws.RealWebSocket.onReadMessage(RealWebSocket.java:323)
	at okhttp3.internal.ws.WebSocketReader.readMessageFrame(WebSocketReader.java:219)
	at okhttp3.internal.ws.WebSocketReader.processNextFrame(WebSocketReader.java:105)
	at okhttp3.internal.ws.RealWebSocket.loopReader(RealWebSocket.java:274)
	at okhttp3.internal.ws.RealWebSocket$2.onResponse(RealWebSocket.java:214)
	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

[apupier]

fixed in 7.26 and 7.25.1 (no milestone 7.25.1?)

created https://issues.redhat.com/browse/FUSETOOLS2-965 to investigate why it is requiring so much memory (but unless we have more precise pointers, I fear it won’t have an high priority)

[ScrewTSW]

verified working on 7.25.2