presence of quarkus-container-image-s2i extension causes wrong java -jar argument in pod spec

[Ladicek]

Describe the bug

I use the quarkus-container-image-s2i extension to be able to customize the S2I base image for my application. I then oc apply -f target/kubernetes/openshift.yml and oc start-build <app name> --from-dir=target to deploy my application, which is the usual S2I binary build flow.

However, the mere presence of this extension causes a significant difference in how the Kubernetes Deployment (or OpenShift DeploymentConfig) is generated. If the S2I extension is present, the pod spec template contains a full java -jar ... -cp ... command. This command seems to always read java -jar /deployments/application-runner.jar ..., even though the JAR itself is not called application-runner.jar. In case of OpenShift, an env var JAVA_APP_JAR is also generated, and its value is the correct path to the JAR.

This is probably tailored towards the S2I extension building the image itself, but that is a severely restrictive requirement.

Is generating the java -jar ... -cp ... command really necessary? The JDK base images typically know how to use a single JAR in /deployments (which already happens if I don't include the quarkus-container-image-s2i extension).

Expected behavior
I can use the generated target/kubernetes/openshift.yml as is, without change.

Actual behavior
When the quarkus-container-image-s2i extension is present, the generated target/kubernetes/openshift.yml uses extraneous configuration that prevents the deployment from succeeding.

To Reproduce
Steps to reproduce the behavior:

1. Add the quarkus-kubernetes and quarkus-container-image-s2i extensions.
2. Run mvn clean package -DskipTests.
3. See target/kubernetes/*.yml.

Configuration

quarkus.kubernetes.deployment-target=kubernetes,openshift
quarkus.s2i.base-jvm-image=registry.access.redhat.com/openjdk/openjdk-11-rhel7

Additional context
Compared to 1.3.0.Alpha2, this is actually a regression.

[Ladicek]

CC @iocanel @geoand

[geoand]

I don't really know much about what has been for s2i TBH and what the requirements were

[iocanel]

@Ladicek: The artifcat that is uploaded is always renamed to "application-${quarkus.package.runner-suffix}.jar". So, the cmd uses the intended value. The JAR_APP_JAR is outdated, not used and should be removed.

Why do we create a custom command and not use JAVA_APP_JAR?
JAVA_APP_JAR is an environment variable used by the fabric8 images. There is no guarantee that it will work if the user uses an other image.

Why do we rename the artifact?
In order to be able to reference the final destination of the jar in the resulting container we provide quarkus.s2i.jar-path that defaults to /deployments/application-runner.jar.
It felt that this configuration option should be free of the application name and version, so we strip them both.

[maxandersen]

@iocanel any particular reason why jar-path doesn't reflect the app name and version? just se don't have to parameterise that everywhere else or ?

[iocanel]

Convenience mostly.

• It feels simpler for the user to configure, without having to take into consideration the various parameters that need to be combined to get the artifact name .
• Some s2i builder images strip those anyway (see our native base image for example)
• It was much simpler for us to get all involved parts aligned.

[Ladicek]

The artifcat that is uploaded is always renamed to "application-${quarkus.package.runner-suffix}.jar"

This only happens if I let the S2I extension start the S2I build. If I use oc start-build, that obviously doesn't happen. oc start-build is a normal thing to do in my opinion.

If I don't use the S2I extension, I get all the S2I binary build resources generated, and the deployment/deploymentconfig don't include the full java -jar ... invocation, so it works as expected. (Except I can't configure the S2I base image.)

Just adding the S2I extension changes behavior in unexpected ways.

[maxandersen]

@Ladicek just want to be sure you are not conflating s2i source and s2i binary behaviours ?
s2i-extension is doing a s2i binary build.

[maxandersen]

ah - you are saying if you call oc start-build manually things works differently - good point.

[iocanel]

Yeah, I'll work on that.

…

On Tue, Mar 10, 2020, 12:09 Max Rydahl Andersen ***@***.***> wrote: ah - you are saying if you call oc start-build manually things works differently - good point. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7712?email_source=notifications&email_token=AADCEWEH3BPXB755T7FTL3DRGYGWXA5CNFSM4LEPHVWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOKZFUI#issuecomment-597005009>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADCEWHSPMU5YGGRXGZBRJDRGYGWXANCNFSM4LEPHVWA> .

[Ladicek]

Yea, I'm not doing S2I source builds in any way, this is all about S2I binary builds.