Some devfiles are not compatible with Hosted Che (che.openshift.io) due to 3 GB quota limitations

[ibuziuk]

Current Hosted Che "Terms of service" allows using only 3GB of RAM for workspace. At the same time some of the devfiles from the registry like java-web-spring are failing with the quota issue:

NOTE: event though globalMemoryLimit: 2674Mi is set in the meta.yaml, I suspect it does not take into account the jwt-proxy pod

We need to:

• identify the list of problematic devfiles that would fail with the quota issue Some devfiles are not compatible with Hosted Che (che.openshift.io) due to 3 GB quota limitations #13969 (comment)
• try to update defviles to make them compatible with Hosted Che resources (if not possible need to decide if those devfiles should be in the registry )
  • apache-camel-springboot Set back lower memory limits to have stack working by default on che-devfile-registry#46
  • java-mysql Fixing Java MySQL sample devfile to be able to be run on OSIO che-devfile-registry#61
  • java-web-spring Fixed java-web-spring quotas to be able to run on OSIO che-devfile-registry#62

[1] https://www.eclipse.org/che/docs/che-7/hosted-che.html#terms-of-service_{context}

[ibuziuk]

@Katka92 @ScrewTSW could you please provide a list of Hosted Che quota incompatible devfiles from - https://github.com/eclipse/che-devfile-registry/tree/master/devfiles ?

This could be simply tested on prod-preview ?url=https://raw.githubusercontent.com/eclipse/che-devfile-registry/master/devfiles/java-web-spring/devfile.yaml (import via factory) e.g. https://che.prod-preview.openshift.io/f?url=https://raw.githubusercontent.com/eclipse/che-devfile-registry/master/devfiles/java-web-spring/devfile.yaml

[ScrewTSW]

Devfiles failing because of quota issues:

• Apache Camel based on Spring Boot
• Java with Spring Boot and MySQL
• Java Spring Boot

All the other devfiles started correctly for me when I was doing the testing (19.7.2019)

[ibuziuk]

@sleshchenko any comments on this issue. Do you happen to know if we could shrink RAM for those devfiles or current memory settings reflect the absolute minimum ?

[apupier]

in previous version of Che 7, the Apache Camel stack was working. it was using smaller memory values, see #13832 (comment)

[amisevsk]

Related: #11801

[ScrewTSW]

[23.07.2019]
Check for worksapce startup quotes with the latest version of devfile registry at prod-preview:

• ✓ angular
• ✘ apache-camel-springboot [Should be fixed by PR and Follow-up]
• ✓ dotnet
• ✓ golang
• ✓ java-gradle
• ✓ java-maven
• ✘ java-mysql [Should be fixed by PR]
• ✘ java-web-spring [Should be fixed by PR]
• ✓ java-web-vertx
• ✓ nodejs-mongo
• ✓ nodejs-react
• ✓ nodejs
• ✓ php-laravel
• ✓ php-mysql
• ✓ php-symfony
• ✓ php-web-simple
• ✓ python-django
• ✓ python

[sunix]

I don't know if this is the place but we should concider having 5GB quota limitations (and having less users capacity)

[ibuziuk]

@sunix you could add this proposal to the upcoming briefs for Q3, but 5GB quota & less users capacity definitely not smth we are going to address by GA

[l0rd]

@ibuziuk that doesn't look like a blocker right? Setting it as P1. I mean if we cannot reduce the amount of memory we can remove the devfiles from the openshift.io registry.

[ibuziuk]

yeah, not a blocker indeed

[apupier]

I mean if we cannot reduce the amount of memory we can remove the devfiles from the openshift.io registry.

for Apache Camel stack, we can reduce the memory, see eclipse-che/che-devfile-registry#46 and #13832

so nto having Apache Camel stack on che.openshift.io is not blocker?
an alternate solution if there is a different registry to use is to set back the working memory values only in the rh-che repository?

[ibuziuk]

@apupier if it works we would merge it and make available ;-)

[apupier]

@apupier if it works we would merge it and make available ;-)

my last manual tests on preprod are working eclipse-che/che-devfile-registry#46 (comment)

[ibuziuk]

created a separate issue for UD improvement that should be tackled after GA - #14001

[ibuziuk]

All PRs have been merged. Closing