Add Quarkus devfile #144

svor · 2019-11-11T13:25:45Z

What does this PR do?

Adds a devfile to support Qurakus tools.

This devfile includes

2 components:
- dev component is based on quay.io/quarkus/centos-quarkus-maven:19.2.1 which contains Java 8, Maven 3.6.0 and GraalVM 19.2.1
- qurkus plugin (for more information take a look at Add Quarkus plugin che-plugin-registry#291)
2 commands:
- mvn package
- mvn compile quarkus:dev
The application could be debugged by predefined debug configuration in case mvn compile quarkus:dev was executed before.

This devfile doesn't include commands to run native compilation because it requires more than 3GB RAM for workspace in total and it's not available on Hosted Che.

What issues does this PR fix or reference?

eclipse-che/che#14506

sunix · 2019-11-13T08:34:03Z

devfiles/quarkus/devfile.yaml

+  -
+    type: dockerimage
+    alias: maven
+    image: quay.io/eclipse/che-java8-maven:nightly


we should include the ability to run the native compilation to this devfile

could you please clarify why do we need that?

With Quarkus, you have a way to produce a tiny native executable https://quarkus.io/guides/building-native-image

for instance:
https://github.com/sunix/che-quarkus-demo/blob/8f4f4fa8e09158853e9cd900c0fe93cac18da484/devfile.yaml#L109-L121

looks like GraalVM Native Image generation requires at least 2Gi RAM to perform a native image build. So, if we give this value + 1,5Gi for Quarkus VS Code plugin (Java LS, Quarkus LS, Java Debugger) container, it'd be more than 3Gi - it is too much for che.openshift.io

To me we have to produce a devfile for che. Not che.openshift.io.

upstream devfile registry is used on Hosted Che, so all the devfiles in the registry must be compatible with Hosted Che. Otherwise, we need to come up with Hosted Che specific devfile registry (smth. that should be avoided)

looks like GraalVM Native Image generation requires at least 2Gi RAM to perform a native image build. So, if we give this value + 1,5Gi for Quarkus VS Code plugin (Java LS, Quarkus LS, Java Debugger) container, it'd be more than 3Gi - it is too much for che.openshift.io

Could you give a try in a single container with vscode ext for java/quarkus and mvn/graalvm/jdk8 ?

ibuziuk

will it be compatible with Hosted Che (3GB ram)?

tsmaeder · 2019-11-27T10:20:55Z

will it be compatible with Hosted Che (3GB ram)?
modulo native compilation, it should

svor · 2019-11-27T13:08:06Z

@ibuziuk except building a native executable, it should

sunix · 2019-11-27T13:22:15Z

Not including native executable compilation would show only 1/3 of the value of Che for quarkus developers. IMHO

svor · 2019-11-27T14:31:27Z

It is possible to execute native compilation but it'll be failed with OOM on hosted Che, that's why I didn't add commands into devfile. If the user will have more OOM for Che it could add such commands into the workspace or just execute them in the dev terminal

sunix · 2019-11-27T16:53:19Z

@ibuziuk

upstream devfile registry is used on Hosted Che, so all the devfiles in the registry must be compatible with Hosted Che. Otherwise, we need to come up with Hosted Che specific devfile registry (smth. that should be avoided)

If the goal of hosted Che is to show the value of Che to potential/possible users, for a Quarkus devfile, we need to have Quarkus + native compilation. If we don't have that, there is no value compared to a VSCode or another IDE. We need to reconsider the 3Go limitation and give 4 or 5Gigs at least if we cannot optimize it.

ibuziuk · 2019-11-27T16:58:20Z

We need to reconsider the 3Go limitation and give 4 or 5Gigs at least if we cannot optimize it.

isn't it smth you have already raised on the planning? This is a PM decision, so, for now, all the devfiles should be compatible with the 3Gb RAM limits available on Hosted Che - https://www.eclipse.org/che/docs/che-7/hosted-che/#terms-of-service_hosted-che

Signed-off-by: svor <vsvydenk@redhat.com>

amisevsk · 2019-12-20T14:37:46Z

IMO native compilation is a deploy step most of the time (with the caveat there are some minor incompatibilities). If I was developing a quarkus app, I my flow would be something like

Develop using quarkus:dev for hot code reload and testing/debugging
Once ready to deploy, run a builder separately to create and test the native binary.

Native compilation in the workspace is a "nice to have" but not essential, since generally native compilation is something you would do once, at the end of preparing a PR.

amisevsk

LGTM, just a few suggestions.

devfiles/quarkus/devfile.yaml

Signed-off-by: svor <vsvydenk@redhat.com>

sunix · 2019-12-24T10:25:54Z

IMO native compilation is a deploy step most of the time (with the caveat there are some minor incompatibilities). If I was developing a quarkus app, I my flow would be something like

Develop using quarkus:dev for hot code reload and testing/debugging

Once ready to deploy, run a builder separately to create and test the native binary.

Native compilation in the workspace is a "nice to have" but not essential, since generally native compilation is something you would do once, at the end of preparing a PR.

Yes this is nice to have but essential to show the value of Che: this is what is hard to have if you are working on a Quarkus app on a traditional Desktop environment. The current devfile is easy to setup with VSCode + quarkus ext... so what is the point to use Che ?

Signed-off-by: svor <vsvydenk@redhat.com>

nickboldt · 2020-01-06T15:17:34Z

Looks like all of Angel's concerns have been addressed; which only leaves @ibuziuk 's question of 3G vs. 4-5G as the required memory footprint.

Meanwhile upstream the quarkus jdk8 plugin PR is approved: eclipse-che/che-plugin-registry#291

amisevsk

LGTM.

Personally, I'm against adding native compilation as a default, since adding 2Gi to the runtime memory requirements for this workspace is too high a cost for something that generally won't be executed often. I would like to see native compilation added when Che supports something like a short-lived builder container, so that just running the workspace doesn't take 2Gi of quota that is unused 90% of the time.

tsmaeder · 2020-01-06T15:47:08Z

Folks, we should not make merging this PR dependent on the native compilation commands. In the short run, we cannot increase memory on hosted Che. In the short run, we cannot run a separate devfile registry for hosted che.
IMO, we have 3 courses of action open:

Merge the PR "as is"
Wrap native compilation with a script that graciously fails when memory is lacking (aka on hosted che) and run that as the native compile command
Don't add Quarkus support.

@slemeur make a decision, please.

nickboldt · 2020-01-06T18:02:04Z

My $0.02 based on existing CRW 2.1 requirements (eg., https://issues.redhat.com/browse/CRW-586 and https://issues.redhat.com/browse/CRW-329 ) ...

#3 isn't an option - Quarkus support is required for CRW 2.1, and being able to dogfood it in some way in Che 7.7 and in Hosted Che is IMHO a valuable way to ensure it's working downstream too.

#2 seems like the best approach - failing gracefully is an important part of UX when running on disparate clusters. Error message on failure should include detailed call to action so workspace user knows they need to ask for more RAM from their cluster administrator. I would further tell the user that if they don't have access to their administrator, this functionality won't be available (eg., if they need 5G in Hosted Che, they're going to have a bad time.)

tsmaeder · 2020-01-08T14:14:31Z

I would go ahead and merge this PR as is. We can add native compile commands in the next sprint.

slemeur · 2020-01-08T14:19:54Z

+1 on the approach

* Add quarkus devfile Signed-off-by: svor <vsvydenk@redhat.com>

* Added definitions for gwt ide versions since 6.19.0 6.19.0 7.0.0-beta-1.0 7.0.0-beta-2.0 7.0.0-beta-3.0 7.0.0-beta-4.0 next

svor requested review from tolusha and tsmaeder November 11, 2019 13:25

svor self-assigned this Nov 11, 2019

sunix reviewed Nov 13, 2019

View reviewed changes

ibuziuk reviewed Nov 27, 2019

View reviewed changes

nickboldt mentioned this pull request Dec 10, 2019

Unset MAVEN_CONFIG env in Maven based images #160

Merged

svor force-pushed the sv/quarkus branch from a2f7a5e to d90e549 Compare December 19, 2019 09:02

Add quarkus devfile

345f935

Signed-off-by: svor <vsvydenk@redhat.com>

svor force-pushed the sv/quarkus branch from 65255e8 to 345f935 Compare December 19, 2019 10:29

svor marked this pull request as ready for review December 20, 2019 10:14

svor requested review from amisevsk, l0rd, nickboldt, rhopp, skabashnyuk and vparfonov as code owners December 20, 2019 10:14

nickboldt mentioned this pull request Dec 20, 2019

Add Quarkus plugin eclipse-che/che-plugin-registry#291

Merged

amisevsk reviewed Dec 20, 2019

View reviewed changes

devfiles/quarkus/devfile.yaml Outdated Show resolved Hide resolved

devfiles/quarkus/devfile.yaml Show resolved Hide resolved

devfiles/quarkus/devfile.yaml Outdated Show resolved Hide resolved

reference the comments

ce0fb2f

Signed-off-by: svor <vsvydenk@redhat.com>

update plugin name

a4cc003

Signed-off-by: svor <vsvydenk@redhat.com>

amisevsk approved these changes Jan 6, 2020

View reviewed changes

amisevsk merged commit 8f4a62a into master Jan 8, 2020

svor deleted the sv/quarkus branch January 8, 2020 15:04

nickboldt pushed a commit that referenced this pull request Jan 8, 2020

Add Quarkus devfile (#144)

7b8180b

* Add quarkus devfile Signed-off-by: svor <vsvydenk@redhat.com>

l0rd mentioned this pull request Feb 4, 2021

Add ide tooling links to main guides quarkusio/quarkus#14505

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Quarkus devfile #144

Add Quarkus devfile #144

svor commented Nov 11, 2019 •

edited

Loading

sunix Nov 13, 2019

svor Nov 13, 2019

sunix Nov 15, 2019

svor Nov 18, 2019

sunix Nov 27, 2019

ibuziuk Nov 27, 2019

sunix Nov 27, 2019 •

edited

Loading

ibuziuk left a comment

tsmaeder commented Nov 27, 2019

svor commented Nov 27, 2019

sunix commented Nov 27, 2019

svor commented Nov 27, 2019

sunix commented Nov 27, 2019

ibuziuk commented Nov 27, 2019

amisevsk commented Dec 20, 2019

amisevsk left a comment

sunix commented Dec 24, 2019

nickboldt commented Jan 6, 2020 •

edited

Loading

amisevsk left a comment

tsmaeder commented Jan 6, 2020 •

edited

Loading

nickboldt commented Jan 6, 2020 •

edited

Loading

tsmaeder commented Jan 8, 2020

slemeur commented Jan 8, 2020

Add Quarkus devfile #144

Add Quarkus devfile #144

Conversation

svor commented Nov 11, 2019 • edited Loading

What does this PR do?

This devfile includes

What issues does this PR fix or reference?

sunix Nov 13, 2019

Choose a reason for hiding this comment

svor Nov 13, 2019

Choose a reason for hiding this comment

sunix Nov 15, 2019

Choose a reason for hiding this comment

svor Nov 18, 2019

Choose a reason for hiding this comment

sunix Nov 27, 2019

Choose a reason for hiding this comment

ibuziuk Nov 27, 2019

Choose a reason for hiding this comment

sunix Nov 27, 2019 • edited Loading

Choose a reason for hiding this comment

ibuziuk left a comment

Choose a reason for hiding this comment

tsmaeder commented Nov 27, 2019

svor commented Nov 27, 2019

sunix commented Nov 27, 2019

svor commented Nov 27, 2019

sunix commented Nov 27, 2019

ibuziuk commented Nov 27, 2019

amisevsk commented Dec 20, 2019

amisevsk left a comment

Choose a reason for hiding this comment

sunix commented Dec 24, 2019

nickboldt commented Jan 6, 2020 • edited Loading

amisevsk left a comment

Choose a reason for hiding this comment

tsmaeder commented Jan 6, 2020 • edited Loading

nickboldt commented Jan 6, 2020 • edited Loading

tsmaeder commented Jan 8, 2020

slemeur commented Jan 8, 2020

svor commented Nov 11, 2019 •

edited

Loading

sunix Nov 27, 2019 •

edited

Loading

nickboldt commented Jan 6, 2020 •

edited

Loading

tsmaeder commented Jan 6, 2020 •

edited

Loading

nickboldt commented Jan 6, 2020 •

edited

Loading