As part of our migration to OpenJDK 11, delegates will download OpenJDK 11 and get started with it instead of the previous OpenJDK 8 that was used. This means that delegates will have java installed on a different path so any user actions which modify or use older java would be affected. Some of the most common scenarios include adding certificates to the default java keystore and running additional java applications using delegates installed java (e.g. from a profile or init script)
Am I affected?
- I’ve installed additional certificates to the delegate’s default OpenJDK8 truststore - Yes, the delegate will use a different default truststore after the migration.
- I’ve created a custom truststore and configured the delegate to use it - No, the delegate will continue using the custom truststore without issues after migration.
- I’m running an additional java application on delegate - Yes, but not right away. Older OpenJDK8 java installation will remain on delegate for a short period of time after our migration.
What if I don’t take action?
- If you install additional certificates to the default truststore, delegates will not have them any more which can lead to problems connecting to external resources or even to Harness manager causing delegates to fail to register for work.
- If you are running additional java applications, they will fail to start when older OpenJDK8 gets removed from the delegate.
When should I take action?
Harness will start rolling out the migration on May 31, 2022.
Are you removing OpenJDK 8?
OpenJDK 8 which was previously used by delegates will remain in the same location for a short period of time to allow for easier migration.
How to prevent downtime caused by additional certificates?
If you need to use additional certificates it’s best that they are not stored in the default keystore, but a custom one you create. (here’s some keystore best practices). To prevent issues in delegate operation you should follow the instruction on adding a custom keystore, before the delegate migrates to OpenJDK11. Once migration is complete, delegates will automatically start using the same custom keystore from the JAVA_OPTS or WATCHER_OPTS configuration.
What if I run java applications on delegate?
Older OpenJDK8 will not get deleted immediately after migration, you should move your application to being started using new OpenJDK11 once it appears on your delegate. Alternatively you can install additional Java Runtime Environment independent of the one used by delegates that you can use for running your application.
What If I use immutable delegates?
New immutable delegate image with OpenJDK11 will be released, to get migrated your delegate should start using the new image.
Immutable delegate docker images come with java pre-installed and they don’t download it (maybe we can link some immutable delegate docs as a plug here). However you can still get affected by additional certificates issue and should use a custom truststore instead.
Immutable delegate has JAVA_HOME and PATH environment variables configured so invoking java would automatically use OpenJDK11.
What if I use a custom-built delegate image?
For all customers who are using custom-built delegate images(docker-based), if the image was built using any delegate image published before Jun 02, 2022 as the base, then the delegate will fail to start up when JDK11 is rolled out globally on Jun 15, 2022. To properly accommodate the JDK11 rollout you will be required to re-build your custom delegate image using the scripts available in versions published on or after Jun 02, 2022. Everything else outlined in this document in relation to certificates would still apply to custom-built delegate images.