Warning about unsupported argument is thrown into the console when running with Mandrel

[rsvoboda]

Warning about unsupported argument is thrown into the console when running native build using Mandrel image.
This is usability issue, Mandrel is supposed to be the default for Quarkus and therefore no warnings should be in the console log.

Warning shown in the console:

[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] docker run .. 
Warning: Ignoring server-mode native-image argument --no-server.

Steps to reproduce:

git clone https://github.com/quarkus-qe/beefy-scenarios.git
cd beefy-scenarios/
mvn clean verify -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.native-image-xmx=3g -pl 003-quarkus-many-extensions/ -Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel:20.1.0.1.Alpha2-java11

This is applicable to Mandrel only, GraalVM CE doesn't throw this warning.

[jaikiran]

This is applicable to Mandrel only, GraalVM CE doesn't throw this warning.

Hello @rsvoboda, I believe if you build GraalVM from oracle/graal master you would see the same warning with Graal VM CE too. They committed that change (which was then brought into Mandrel) recently oracle/graal#2598 and that change I think will be available in next release of Graal VM. I think once Quarkus uses 20.2.x of Graal VM as default we can remove this --no-server option that we add to the native-image launch.

[rsvoboda]

It's Mandrel specific - see This is applicable to Mandrel only, GraalVM CE doesn't throw this warning. in the description

@gsmet / @geoand Is there a way to detect that Mandrel is used and skip the --no-server argument? Asking because Mandrel is supposed to be the default (at least for Red Hat) and the experience should be "warning-less"

[geoand]

@rsvoboda what does native-image --version return?

Is there is anything in that output that we can use to differentiate Mandrel?

[galderz]

./native-image --version
GraalVM Version beb2fd6 (Mandrel Distribution) (Java Version 11.0.9-internal)

@zakkak has been worked on the packaging of Mandrel, maybe there's something we can do on that side, let's see what he says. Otherwise we can indeed execute the above and see if Mandrel Distribution or Mandrel is in it, and decide whether to add --no-server based on that.

[galderz]

Oh, I think @jaikiran's option above is preferrable. Wait and no fix :)

[geoand]

I think that for 1.7, we should add the solution above, since we don't want users to see this warning with Mandrel. We can always remove or alter it when we move to GraalVM 20.2

[galderz]

@jaikiran Are you completely sure this is due to a backport to Mandrel? useServer is true in Mandrel 20.1 branch.

[galderz]

I think this issue is more due to the packaging that we do for Mandrel, which is slightly different to the one done for Oracle GraalVM.

[galderz]

@geoand Wait until @zakkak replies before implementing anything. It could be that maybe we can avoid the Quarkus change by adjusting the packaging. Let's see what he says.

[geoand]

Well, it was too easy so I just did: #11088.

We don't need to merge it obviously, just keep in the back of our minds in case it's needed :)

[galderz]

@geoand LOL, so quick! hehe :)

[jaikiran]

@jaikiran Are you completely sure this is due to a backport to Mandrel? useServer is true in Mandrel 20.1 branch.

@galderz, you are right - I had a more detailed look at the Mandrel code and it looks like this could be due to something else.

[zakkak]

Hello all, sorry for the delay, it appears that this is indeed a packaging/configuration mismatch.
Mandrel is using a native-image bash script, while GraalVM CE is using a binary native-image (this is controlled by -Dcom.oracle.graalvm.isaot=true).
In https://github.com/graalvm/mandrel/blob/56d4ee1b28d9099d60929b3bba0a94429f857759/substratevm/src/com.oracle.svm.driver/src/com/oracle/svm/driver/NativeImage.java#L1216 we see that only if IS_AOT is true it will use the native image server.

Given that --no-server will be the default behaviour from 20.2 onwards I suggest "fixing" this on the quarkus side (#11088).

[geoand]

I'll take the PR out of draft then, thanks @zakkak for the information.

[jaikiran]

Given that --no-server will be the default behaviour from 20.2 onwards I suggest "fixing" this on the quarkus side (#11088).

Hello @zakkak, I don't think we can fix this on the Quarkus side (or rather I don't think there's a fix really for this). If we remove the --no-server from Quarkus for Mandrel then this will launch a server in the background to run the builds. That's not something we want. In 20.2.x of Graal, they toggled the "default" which means that they don't launch any server at all unless explicitly asked to.

[jaikiran]

Mandrel is using a native-image bash script, while GraalVM CE is using a binary native-image

Is that intentional? In the build process of the Graal VM mx build, there is an option to make sure that these generated "tools" are native applications themselves.

[zakkak]

Given that --no-server will be the default behaviour from 20.2 onwards I suggest "fixing" this on the quarkus side (#11088).

Hello @zakkak, I don't think we can fix this on the Quarkus side (or rather I don't think there's a fix really for this). If we remove the --no-server from Quarkus for Mandrel then this will launch a server in the background to run the builds. That's not something we want. In 20.2.x of Graal, they toggled the "default" which means that they don't launch any server at all unless explicitly asked to.

I think there is a misunderstanding here. Due to #11060 (comment) Mandrel cannot run the server (it doesn't run no matter if you use --no-server or not)

[zakkak]

Mandrel is using a native-image bash script, while GraalVM CE is using a binary native-image

Is that intentional? In the build process of the Graal VM mx build, there is an option to make sure that these generated "tools" are native applications themselves.

Yes this is intentional. The bash script allows us to tweak things without altering source code.
See https://github.com/graalvm/mandrel-packaging/blob/14e3ebb4b80010cae4e01c319fc55afb70c028f4/buildJDK.sh#L98

If this turns out to cause trouble we will have to revisit that decision.

[jaikiran]

Yes this is intentional. The bash script allows us to tweak things without altering source code.
See https://github.com/graalvm/mandrel-packaging/blob/14e3ebb4b80010cae4e01c319fc55afb70c028f4/buildJDK.sh#L98

Thank you, that helped :) Mandrel is new to me, I wasn't aware of these changes.