Submission Request - Java11 on ARM64 Template about store

[alexellis]

Hi @mjallday I can't see any explanation on how this is different from the existing template.

Most base images like the one we use here are multi-arch, does the provided template not work for you?

Alex

[mjallday]

Which template specifically are you referring to? I tried the existing java11 one and it failed with an invalid image format or similar message I’ll reproduce and if it works then I’ll close this ticket.

On Mon, Apr 20, 2020 at 13:06 Alex Ellis ***@***.***> wrote: Hi @mjallday <https://github.com/mjallday> I can't see any explanation on how this is different from the existing template. Most base images like the one we use here are multi-arch, does the provided template not work for you? Alex — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5S6HAS66DL7WQS7JMVQTRNSTMFANCNFSM4MMUKUJA> .

-- Marshall Jones

[alexellis]

This one: https://www.openfaas.com/blog/get-started-with-java-openjdk11/

[alexellis]

It uses the following images: openjdk:11-jdk-slim and openjdk:11-jre-slim, might be worth you checking if they are multi-arch on hub.docker.com?

You should specifically build your images on your ARM host unless you're a wizard with qemu-static.

Alex

[alexellis]

I had no issues with the template, it built and ran as expected?

[mjallday]

Here's what I'm seeing when I use the existing template.

kubectl -n openfaas-fn logs pod/fn-dyneti-secure-compute-798b696f75-22qcd

standard_init_linux.go:211: exec user process caused "exec format error"

Container runs fine when I use the template linked in my suggestion above.

I'm not an expert on these cross arch builds so it's possible I'm doing something incorrect here but the only change I've made is changing the base image for the Java template to an ARM one.

[mjallday]

Just to clarify on that last comment. Here's a diff from the Java11 template:

diff java11 java11-arm64

diff java11/Dockerfile java11-arm64/Dockerfile
1c1
< FROM openjdk:11-jdk-slim as builder
---
> FROM arm64v8/openjdk:11.0.6-jdk as builder
29c29
< RUN find .
---
> RUN find .
31,32c31,32
< FROM openfaas/of-watchdog:0.7.6 as watchdog
< FROM openjdk:11-jre-slim as ship
---
> FROM openfaas/of-watchdog:0.7.7-arm64 as watchdog
> FROM arm64v8/openjdk:11.0.6-jdk as ship
diff java11/README.md java11-arm64/README.md
1c1
< ## Template: java8
---
> ## Template: java11
3c3
< The Java8 template uses gradle as a build system.
---
> The Java11 template uses gradle as a build system.
Common subdirectories: java11/entrypoint and java11-arm64/entrypoint
Common subdirectories: java11/function and java11-arm64/function
Common subdirectories: java11/gradle and java11-arm64/gradle
Common subdirectories: java11/model and java11-arm64/model
diff java11/settings.gradle java11-arm64/settings.gradle
5c5
<  *
---
>  *
10c10
< rootProject.name = 'java8'
---
> rootProject.name = 'java11'
diff java11/template.yml java11-arm64/template.yml
1c1
< language: java11
---
> language: java11-arm64
3c3
<   You have created a function using the java11 template which uses an LTS
---
>   You have created a function using the java11 template on ARM64 which uses an LTS

IDK if there's a way to pass the base image in as an argument. That would remove the need for this entirely either way.

[alexellis]

There's no need for a separate template IMHO. How and where are you building the image to get the exec error? As I say, you'll need to build on an arm64 device.

[mjallday]

I've been using docker's buildx to build.

Let me see if I can get my hands on a native ARM64 device to try building the above template and if that works we can close this out.

Thanks for your patience.

[mjallday]

just posting notes in this thread while i debug this.

i'm not sure how that would work here @alexellis.

i'm looking at the difference between the docker image used for the java-11 template you're using and the one i've created. the only real difference is the base image.

• https://github.com/docker-library/openjdk/blob/master/11/jdk/slim/Dockerfile latest openjdk:11-jdk-slim version
• https://github.com/docker-library/openjdk/blob/bce2fa373dc270cccf539a8e31b5f2a432d23738/11/jdk/Dockerfile#L55 - commit tagged for https://hub.docker.com/r/arm64v8/openjdk/ which is what is referenced in the diff above (arm64v8/openjdk:11.0.6-jdk)

i'm comparing what the different base images are doing, it's the same image as you can see from the links above except there's a compile flag being used to download a particular version of the jdk.

dpkgArch="$(dpkg --print-architecture) and then followed by wget -O openjdk.tgz "${JAVA_BASE_URL}${upstreamArch}_linux_${JAVA_URL_VERSION}.tar.gz" --progress=dot:giga; which downloads a different version of the jdk.

so at a minimum they are using different builds of the jdk. clearly in your example it looks like you're running on an arm platform so this isn't giving me much to go on yet so i've still got an open question (that i'm debugging) about why yours works and mine doesn't.

[alexellis]

It works, I tried it and showed you the output. You just need to build on an arm64 machine. Am I missing something?

[mjallday]

i understand you've demonstrated it works for you. i'm just unsure why it's not working for me but the alternative template is. possibly it's because i'm building using docker buildx rather than native arm but i haven't understood why it would then work when using a native arm jdk...

am re-creating the scenario by building directly on our arm cluster....

[mjallday]

going to close this out until i have reproduced. i'll re-open once i've built the image without an emulator and continue to see the issue.