Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modernize and consolidate JDKs usage across all stages of the build. Update JDK-14 requirement, switch to JDK-17 instead #1368

Merged
merged 4 commits into from
Oct 15, 2021

Conversation

reta
Copy link
Collaborator

@reta reta commented Oct 14, 2021

Signed-off-by: Andriy Redko andriy.redko@aiven.io

Description

Update DEVELOPER_GUIDE.md and java-versions.properties.

Issues Resolved

Part of #1351

Check List

  • New functionality includes testing.
    • All tests pass
  • New functionality has been documented.
    • New functionality has javadoc added
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@@ -70,8 +70,8 @@ Start by running the test suite with `gradlew check`. This should complete witho
OpenSearch Build Hamster says Hello!
Gradle Version : 6.6.1
OS Info : Linux 5.4.0-1037-aws (amd64)
JDK Version : 14 (JDK)
JAVA_HOME : /usr/lib/jvm/java-14-openjdk-amd64
JDK Version : 11 (JDK)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we lowered it to 11

@opensearch-ci-bot
Copy link
Collaborator

Can one of the admins verify this patch?

@@ -49,7 +49,7 @@ Fork [opensearch-project/OpenSearch](https://github.com/opensearch-project/OpenS

OpenSearch builds using Java 11 at a minimum. This means you must have a JDK 11 installed with the environment variable `JAVA_HOME` referencing the path to Java home for your JDK 11 installation, e.g. `JAVA_HOME=/usr/lib/jvm/jdk-11`.

By default, tests use the same runtime as `JAVA_HOME`. However, since OpenSearch also supports JDK 8 as the runtime, the build supports compiling with JDK 11 and testing on a different version of JDK runtime. To do this, set `RUNTIME_JAVA_HOME` pointing to the Java home of another JDK installation, e.g. `RUNTIME_JAVA_HOME=/usr/lib/jvm/jdk-8`.
By default, the test tasks use bundled JDK runtime, configured in `buildSrc/version.properties` and set to JDK 17 (LTS). Other kind of test tasks (integration, cluster, ... ) use the same runtime as `JAVA_HOME`. However, since OpenSearch supports JDK 8/17 as the runtime, the build supports compiling with JDK 11 and testing on a different version of JDK runtime. To do this, set `RUNTIME_JAVA_HOME` pointing to the Java home of another JDK installation, e.g. `RUNTIME_JAVA_HOME=/usr/lib/jvm/jdk-8`. Alernatively, the runtime JDK version could be provided as the command line argument, using combination of `runtime.java=<major JDK version>` property and `JAVA<major JDK version>_HOME` environment variable, for exampe `./gradlew -Druntime.java=17 ...` (in this case, the tooling expects `JAVA17_HOME` enviroment variable to be set).

To run the full suite of tests you will also need `JAVA8_HOME`, `JAVA11_HOME`, and `JAVA14_HOME`. They are required by the [backwards compatibility test](./TESTING.md#testing-backwards-compatibility).
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The JAVA14_HOME is still needed, we checkout 1.x/1.0 branches and they do reference JDK-14

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, JAVA14_HOME is only used for building OpenSearch 1.0, it's a compromise for the smooth transition with Elasticsearch 7.10.2 🙂.

@@ -27,6 +27,6 @@
# specific language governing permissions and limitations
# under the License.
#
OPENSEARCH_BUILD_JAVA=openjdk14
OPENSEARCH_RUNTIME_JAVA=openjdk14
OPENSEARCH_BUILD_JAVA=openjdk17
Copy link
Collaborator Author

@reta reta Oct 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dblock should we lower it to openjdk11 and runtime to 8 like .ci/java-versions.properties?

OPENSEARCH_BUILD_JAVA=openjdk11
OPENSEARCH_RUNTIME_JAVA=java8

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we should!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@opensearch-ci-bot
Copy link
Collaborator

✅   DCO Check Passed 4420f2c1f2313c6ba4666d936f4c1826d120bf16

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Wrapper Validation success 4420f2c1f2313c6ba4666d936f4c1826d120bf16

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Precommit success 4420f2c1f2313c6ba4666d936f4c1826d120bf16

…Update JDK-14 requirement, switch to JDK-17 instead

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Wrapper Validation success e18dbd8

@opensearch-ci-bot
Copy link
Collaborator

✅   DCO Check Passed e18dbd8

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Precommit success e18dbd8

@@ -49,7 +49,7 @@ Fork [opensearch-project/OpenSearch](https://github.com/opensearch-project/OpenS

OpenSearch builds using Java 11 at a minimum. This means you must have a JDK 11 installed with the environment variable `JAVA_HOME` referencing the path to Java home for your JDK 11 installation, e.g. `JAVA_HOME=/usr/lib/jvm/jdk-11`.

By default, tests use the same runtime as `JAVA_HOME`. However, since OpenSearch also supports JDK 8 as the runtime, the build supports compiling with JDK 11 and testing on a different version of JDK runtime. To do this, set `RUNTIME_JAVA_HOME` pointing to the Java home of another JDK installation, e.g. `RUNTIME_JAVA_HOME=/usr/lib/jvm/jdk-8`.
By default, the test tasks use bundled JDK runtime, configured in `buildSrc/version.properties` and set to JDK 17 (LTS). Other kind of test tasks (integration, cluster, ... ) use the same runtime as `JAVA_HOME`. However, since OpenSearch supports JDK 8/17 as the runtime, the build supports compiling with JDK 11 and testing on a different version of JDK runtime. To do this, set `RUNTIME_JAVA_HOME` pointing to the Java home of another JDK installation, e.g. `RUNTIME_JAVA_HOME=/usr/lib/jvm/jdk-8`. Alernatively, the runtime JDK version could be provided as the command line argument, using combination of `runtime.java=<major JDK version>` property and `JAVA<major JDK version>_HOME` environment variable, for exampe `./gradlew -Druntime.java=17 ...` (in this case, the tooling expects `JAVA17_HOME` environment variable to be set).
Copy link
Collaborator

@tlfeng tlfeng Oct 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Andriy, a little concern regarding the expression "OpenSearch supports JDK 8/17 as the runtime". 😄
My concern is if listing 2 JDK versions, will it mislead the readers that only the 2 versions are supported? Actually other versions are able to use as runtime.
In my opinion, the original expression "However, since OpenSearch supports JDK 8 as the runtime" aims to emphasize the lowest JDK version for the runtime.
It's fine if there is actually no ambiguity on this expression.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely agree, changing the phrasing, thank you

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! While the original expression might also have a little confusion - whether only JDK 8 is supported as the runtime. 😂 Haha, anyway, a good solution might be to put the supporting matrix of OpenSearch and JVM in somewhere in user's documentation, but it's out of scope.
Glad to see you improving the developer guide!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tlfeng , I think the build matrix is the goal, hopefully we will get there soon, discussion is ongoing in opensearch-project/opensearch-build#732

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for providing the link 😄 (seems there are many GitHub issues regarding the JDK versions). I will keep an eye on the discussion.

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Wrapper Validation success f55b0ea

@opensearch-ci-bot
Copy link
Collaborator

✅   DCO Check Passed f55b0ea

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Precommit success f55b0ea

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Wrapper Validation success d3ab87c17fe74c8002ee109214f060c5d61e0694

@opensearch-ci-bot
Copy link
Collaborator

✅   DCO Check Passed d3ab87c17fe74c8002ee109214f060c5d61e0694

@opensearch-ci-bot
Copy link
Collaborator

❌   Gradle Precommit failure d3ab87c17fe74c8002ee109214f060c5d61e0694
Log 1323

@@ -101,8 +101,9 @@ public void apply(Project project) {
JavaVersion minimumCompilerVersion = JavaVersion.toVersion(Util.getResourceContents("/minimumCompilerVersion"));
JavaVersion minimumRuntimeVersion = JavaVersion.toVersion(Util.getResourceContents("/minimumRuntimeVersion"));

File runtimeJavaHome = findRuntimeJavaHome();

Optional<File> runtimeJavaHomeOpt = findRuntimeJavaHome();
Copy link
Collaborator Author

@reta reta Oct 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dblock @tlfeng found this interesting issue (and hopefully fixed it): when RUNTIME_JAVA_HOME is set but is the same as JAVA_HOME, the build ignores RUNTIME_JAVA_HOME altogether and basically uses the whatever is set in buildSrc/version.properties as bundled JDK. Practically, it means that we cannot run build + all tests using the same JDK version. It is very easy to verify:

 gradle ':server:test' --tests "org.opensearch.snapshots.SnapshotResiliencyTests.testConcurrentSnapshotDeleteAndDeleteIndex"  -Dtests.security.manager=true -Dtests.jvm.argline="-XX:TieredStopAtLevel=1" -Dtests.locale=th -Dtests.timezone=Asia/Saigon -Druntime.java=11

Will span JDK-11 for Gradle and JDK-17 for tests:

image

Probably could backport it to 1.x as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice one. Agreed.

Copy link
Collaborator

@tlfeng tlfeng Oct 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Impressed by your enquiring mind! 🏆

…_JAVA_HOME == JAVA_HOME

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
@dblock
Copy link
Member

dblock commented Oct 14, 2021

This makes me so happy @reta, thank you, we don't pay you enough to work on OSS and I hope someone does :)
We've had this whole "lower to JDK11" issue open for months and were dragging to address it.

@opensearch-ci-bot
Copy link
Collaborator

✅   DCO Check Passed fe6157f

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Wrapper Validation success 4349dbf

@opensearch-ci-bot
Copy link
Collaborator

✅   DCO Check Passed 4349dbf

@reta
Copy link
Collaborator Author

reta commented Oct 14, 2021

Thanks a lot @dblock , happy to help and help to drive it to the completion (with your enormous help), thanks a mill!

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Precommit success 4349dbf

@tlfeng tlfeng added Build Libraries & Interfaces documentation Improvements or additions to documentation v1.2.0 Issues related to version 1.2.0 v2.0.0 Version 2.0.0 labels Oct 14, 2021
@tlfeng
Copy link
Collaborator

tlfeng commented Oct 14, 2021

start gradle check

@opensearch-ci-bot
Copy link
Collaborator

❌   Gradle Check failure 4349dbf
Log 693

Reports 693

@tlfeng
Copy link
Collaborator

tlfeng commented Oct 14, 2021

In Log 693:

Tests with failures:
 - org.opensearch.repositories.azure.AzureBlobStoreRepositoryTests.testIndicesDeletedFromRepository

---

> Task :plugins:repository-azure:internalClusterTest

REPRODUCE WITH: ./gradlew ':plugins:repository-azure:internalClusterTest' --tests "org.opensearch.repositories.azure.AzureBlobStoreRepositoryTests.testIndicesDeletedFromRepository" -Dtests.seed=6D3A4C2E37516B12 -Dtests.security.manager=true -Dtests.jvm.argline="-XX:TieredStopAtLevel=1" -Dtests.locale=vi-VN -Dtests.timezone=Asia/Phnom_Penh -Druntime.java=17

org.opensearch.repositories.azure.AzureBlobStoreRepositoryTests > testIndicesDeletedFromRepository FAILED
    java.lang.AssertionError: AcknowledgedResponse failed - not acked
    Expected: <true>
         but: was <false>

@reta
Copy link
Collaborator Author

reta commented Oct 14, 2021

Thanks a lot @tlfeng, was checking the tests output, this is unexpected:

[2021-10-15T05:27:50,780][WARN ][o.o.t.n.MockNioTransport ] [transport_client_node_s1] Slow execution on network thread [400 milliseconds]
java.lang.RuntimeException: Slow exception on network thread
	at org.opensearch.transport.nio.MockNioTransport$TransportThreadWatchdog.maybeLogElapsedTime(MockNioTransport.java:420) [framework-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
	at org.opensearch.transport.nio.MockNioTransport$TransportThreadWatchdog.unregister(MockNioTransport.java:412) [framework-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
	at org.opensearch.transport.nio.TestEventHandler.handleRead(TestEventHandler.java:167) [framework-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
	at org.opensearch.nio.NioSelector.handleRead(NioSelector.java:433) [opensearch-nio-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
	at org.opensearch.nio.NioSelector.processKey(NioSelector.java:259) [opensearch-nio-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
	at org.opensearch.nio.NioSelector.singleLoop(NioSelector.java:187) [opensearch-nio-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
	at org.opensearch.nio.NioSelector.runLoop(NioSelector.java:144) [opensearch-nio-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT]
	at java.lang.Thread.run(Thread.java:833) [?:?]

AFAIK, this repository plugin tests don't simulate network issues, but I will recheck tomorrow morning.
Thanks again!

@tlfeng
Copy link
Collaborator

tlfeng commented Oct 14, 2021

Thanks for your explanation for the repository plugin test 😄. I sometime saw some kinds of network issues with those tests, but didn't investigate more.
The above failure is not reproducible in my host, so I will trigger the check again. start gradle check

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Check success 4349dbf
Log 695

Reports 695

@dblock
Copy link
Member

dblock commented Oct 15, 2021

The gradle check is still using Java 14.

=======================================
OpenSearch Build Hamster says Hello!
  Gradle Version        : 6.6.1
  OS Info               : Linux 5.4.0-1045-aws (amd64)
  JDK Version           : 14 (AdoptOpenJDK)
  JAVA_HOME             : /var/CITOOL/tools/hudson.model.JDK/JDK14
  Random Testing Seed   : 61237CACA4283E2D
  In FIPS 140 mode      : false
=======================================

I imagine this comes hardcoded from the infrastructure that runs gradle checks. We need it to start picking up Java version from https://github.com/opensearch-project/OpenSearch/blob/main/.ci/java-versions.properties#L16.

@peternied @peterzhuamazon where/how do we make this happen?

@dblock dblock merged commit 8ea3364 into opensearch-project:main Oct 15, 2021
@reta
Copy link
Collaborator Author

reta commented Oct 15, 2021

@dblock the JDK-14 is coming from the CI build image, it has JAVA_HOME set to AdoptJDK-14 distribution, the pull request is being finalized (testing it right), should fix that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Build Libraries & Interfaces documentation Improvements or additions to documentation v1.2.0 Issues related to version 1.2.0 v2.0.0 Version 2.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants