Java-buildpack: Getting error while use Azul Zulu JDK in PCF microservices

The location to which you point the buildpack, i.e. repository_root, must be a valid repository. There is no index.yml (at least when I looked just now) at that location.

See https://github.com/cloudfoundry/java-buildpack/blob/main/docs/extending-repositories.md.

Hmm, it looks like there used to be an index.yml at that location, but I don't see it any more. Let me ask around and see what I can find.

In the meantime, if you create your own index.yml, host it somewhere (doesn't matter) and point to the files at that location (i.e. https://cdn.azul.com/zulu/bin/zulu9.0.7.1-jdk9.0.7-linux_x64.tar.gz), you can work around this.

We have used the below variables in manifest.yml of application-
JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: "https://example.com:8443/nexus/repository/SRET/com/example/sret/AppD_zulu11.48.21-ca-jdk/11.0.11-linux_x64/AppD_zulu11.48.21-ca-jdk-11.0.11-linux_x64.gz"}, {version: 11.0.+}]'
JBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

OK, this needs to be slightly different. The repository_root points to the folder where your index.yml is located. So the URL that the JBP uses to download the index.yml is repository_root/index.yml.

The JBP will then read index.yml, pick the latest version matching the version filter you specify and download the resource referenced from index.yml for that version.

Hi Dmikusa,

So does that mean both the Zulu JDK as well as the index.yml should be in the same location?

Ok I see what you are saying, the JBP_CONFIG_ZULU_JRE should be setup as

JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: "insert-full-URL-to-index-yml-on-another-server"}, {version: 11.0.+}]'

It needs to be the full URL to the folder/directory where the index.yml resides. The buildpack will append /index.yml to it when it generates the URL to download the index.yml file. So your repository_root should not end with /index.yml.

It seems that it is picking the JVM from this path https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre8u282%2B8-linux-amd64.tar.gz. Where is this configured?

@ajay-dbs - This is likely the reason:

[ConfigurationUtils] WARN User config value for 'jres' is not valid, existing property not present

It's ignoring part of your configuration. Your JBP_CONFIG_COMPONENTS looks OK to me, but you're going to want to look more closely at what is going on there. It is not applying that part of the config, so it's not picking your desired JDK.

Is it because of a missing ":" between JBP_CONFIG_COMPONENTS and the value ?

Should it be JBP_CONFIG_COMPONENTS: '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

It depends on how you set the env variables. If you set them in the manifest it should have a : between it. If you are setting them with cf set-env then it's just name val.

Hi Team,

Application team has used this variable in manifest.yml file.
JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: "https://example.com:8051/pcf"}, {version: 11.0.+}]'
JBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

@ajay-dbs since you are adding the env variables in a manifest.yml , it seems the missing colon maybe the problem. Please fix it as

JBP_CONFIG_COMPONENTS: '{jres: ["JavaBuildpack::Jre::ZuluJRE"]}'

[Buildpack] ERROR Finalize failed with exception #https://cdn.azul.com/zulu/bin/index.yml>
Zulu JRE error: Unable to find cached file for https://cdn.azul.com/zulu/bin/index.yml

BTW the link to https://cdn.azul.com/zulu/bin/index.yml has been restored now.

[ERR] [ConfigurationUtils] WARN User config value for 'version' is not valid, existing property not present

Is a different but similar error. It seems to now be accepting jres which is good. You can see it's actually running the Zulu container now too.

In this case, it now doesn't like the part where you're trying to set the version to 11.0.+. What you have there isn't quite right.

JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: "https://example.com:8051/pcf"}, {version: 11.0.+}]'

should be

JBP_CONFIG_ZULU_JRE: '[jre: {repository_root: "https://example.com:8051/pcf", version: 11.0.+}]'

The version and repository_root are on the same jre object. When in doubt, you can always look at the associated config/ file. The JBP_CONFIG_* config you add, needs to match the format of the config file, as it gets overlaid on top of the config.

See the structure for Zulu: https://github.com/cloudfoundry/java-buildpack/blob/main/config/zulu_jre.yml#L22-L24

021-06-14T13:14:15.960+05:30 [STG/0] [ERR] [Buildpack] ERROR Detect failed with exception #

I recall seeing something like this in the past if the cache got messed up with the app. Try pushing your app under a new name like "my-cool-app-2" or something that's unique & new. If that fixes it, you'll either need to delete and re-push your app or have your administrator clear the buildpacks blobstore cache.

https://apidocs.cloudfoundry.org/16.13.0/blobstores/delete_all_blobs_in_the_buildpack_cache_blobstore.html

Note the latter will clear the cache for all buildpacks. While this is not destructive, it will force all buildpacks to redownload all resources the next time an application is staged.

We have tried to clear cache and also tried to deploy app with completely new name as well as route. Still the same issue.

This will normally fix this type of problem, so it's good to know it's not helping here. It probably means there is something different happening.

WARNING: buildpack script '/bin/detect' is not executable
[Buildpack] ERROR Detect failed with exception #<RuntimeError: Zulu JRE error: Unable to find cached file for https://zulu-index-file.dev.apps.example.com/index.yml>
Zulu JRE error: Unable to find cached file for https://zulu-index-file.dev.apps.example.com/index.yml
stat /tmp/buildpacks/674495fe521621eeb364a353eb511ee3/bin/detect: no such file or directory

What worries me, besides the caching error, is the WARNING about /bin/detect and the `stat: no such file or directory error. Those should happen, and wouldn't happen with the buildpacks that we package with releases.

Where are you getting your buildpack? Are you downloading it from the Releases page & uploading it to CF? Are you using a URL to the github page? If so, what is the exact URL? Are you getting the buildpack from somewhere else? Are you packaging your own buildpack? If so, please try using the one from the Releases page or another known working buildpack as a baseline test to see if that works as expected, and also please indicate how you are packaging up the buildpack? Any additional details you can provide might help to spot the issue or help with reproducing the issue.

Please continue to push as a new app name while you continue to test because we want to ensure that we're ruling out caching issues.

Thanks

A couple more questions... Was this working previously and broke recently? If so, what has changed recently? Did you upgrade buildpack versions? Did you change files on your server hosting Zulu? Were there new Zulu updates put onto your server? If it has never worked or this is the first time you're trying it, let us know that as well.

Thanks

@mells82 I think the content of index.yml should be

---
1.8.0_212: https://cdn.azul.com/zulu/bin/zulu8.38.0.13-ca-jre8.0.212-linux_x64.tar.gz
1.8.0_222: https://cdn.azul.com/zulu/bin/zulu8.40.0.25-ca-jre8.0.222-linux_x64.tar.gz
1.8.0_232: https://cdn.azul.com/zulu/bin/zulu8.42.0.23-ca-jre8.0.232-linux_x64.tar.gz
1.8.0_242: https://cdn.azul.com/zulu/bin/zulu8.44.0.11-ca-jre8.0.242-linux_x64.tar.gz
1.8.0_252: https://cdn.azul.com/zulu/bin/zulu8.46.0.19-ca-jre8.0.252-linux_x64.tar.gz
1.8.0_265: https://cdn.azul.com/zulu/bin/zulu8.48.0.53-ca-jre8.0.265-linux_x64.tar.gz
1.8.0_275: https://cdn.azul.com/zulu/bin/zulu8.50.0.51-ca-jre8.0.275-linux_x64.tar.gz
1.8.0_282: https://cdn.azul.com/zulu/bin/zulu8.52.0.23-ca-jre8.0.282-linux_x64.tar.gz
1.8.0_292: https://cdn.azul.com/zulu/bin/zulu8.54.0.21-ca-jre8.0.292-linux_x64.tar.gz
11.0.3: https://cdn.azul.com/zulu/bin/zulu11.31.11-ca-jre11.0.3-linux_x64.tar.gz
11.0.4: https://cdn.azul.com/zulu/bin/zulu11.33.15-ca-jre11.0.4-linux_x64.tar.gz
11.0.5: https://cdn.azul.com/zulu/bin/zulu11.35.15-ca-jre11.0.5-linux_x64.tar.gz
11.0.6: https://cdn.azul.com/zulu/bin/zulu11.37.17-ca-jre11.0.6-linux_x64.tar.gz
11.0.7: https://cdn.azul.com/zulu/bin/zulu11.39.15-ca-jre11.0.7-linux_x64.tar.gz
11.0.8: https://cdn.azul.com/zulu/bin/zulu11.41.23-ca-jre11.0.8-linux_x64.tar.gz
11.0.9: https://cdn.azul.com/zulu/bin/zulu11.43.55-ca-jre11.0.9.1-linux_x64.tar.gz
11.0.10: https://cdn.azul.com/zulu/bin/zulu11.45.27-ca-jre11.0.10-linux_x64.tar.gz
11.0.11: https://cdn.azul.com/zulu/bin/zulu11.48.21-ca-jre11.0.11-linux_x64.tar.gz

removing the https create issue where the buildpack would not download the jre.

We have downloaded java offline buildpack from pivortal and kept in PCF repository and then use buildpack from PCF repository.
This is the first time we are trying to run app with Azul Zulu JDK. By default oracle JDK is used with Bellsoft VM and this Bellsoft VM not supporting Object Instance Tracking. So we are trying to use Azul Zulu JDK.

OK, thanks for this info. Things are making more sense now.

The way that the Tanzu buildpack is packaged, it is done in "offline" mode. See here, we run this script to package it.

When in "offline" mode, you only get what is packaged into the bundle. The JBP cannot download other things.

From the docs for "offline":

It packages the latest version of each dependency (as configured in the config/ directory) and disables remote_downloads.

https://github.com/cloudfoundry/java-buildpack/#offline-package

It does this because it's meant to run in an offline environment with no Internet access.

I tried in a lab with an offline JBP and I get exactly the same error as you:

   2021-06-17T15:21:56.72-0400 [STG/0] ERR [Buildpack]                      ERROR Finalize failed with exception #<RuntimeError: Zulu JRE error: Unable to find cached file for https://cdn.azul.com/zulu/bin/index.yml>
   2021-06-17T15:21:56.72-0400 [STG/0] ERR Zulu JRE error: Unable to find cached file for https://cdn.azul.com/zulu/bin/index.yml
   2021-06-17T15:21:56.72-0400 [STG/0] ERR Failed to compile droplet: Failed to run finalize script: exit status 1

This is because that file doesn't exist in the offline cache and in offline mode, it will only look in the cache.

If you want to use Azul Zulu in an offline buildpack, you need to package the buildpack yourself with Zulu in it. Otherwise, you need to use an online version of the buildpack. To package the buildpack, see here and make sure you adjust the components.yml prior to packaging. You want that file to indicate Zulu.

Using the online buildpack works, but as @RageZBla said the index.yml needs to be formatted correctly. At the moment, the index.yml at https://cdn.azul.com/zulu/bin/index.yml isn't formatted correctly. It's missing the protocol, which causes issues. Make sure that your index.yml is structured like the example in @RageZBla's comment.

thanks for the report, index.yml has been updated: https://cdn.azul.com/zulu/bin/index.yml

@ajay-dbs If you are in an offline environment, you need to package the buildpack yourself. For someone else to do it for you, requires legal clearance due to the requirements of redistributing software. Not to mention, the security aspects of distributing trusted software. The easiest way forward is to package the buildpack yourself.

The process is documented here. You do need to package from a computer that has Internet access because it needs to download the dependencies, however, it's only a couple of commands and shouldn't take more than a few minutes with a reasonably fast Internet connection.